Ubuntu20.04 GCC10链接阶段报va_end未定义引用错误排查

Ubuntu 20.04环境、gcc-10编译器下，链接多个动态库生成可执行文件时触发如下报错：

/usr/bin/ld: /home/project/folder2/bin/libInterface.so: undefined reference to `va_end'

已通过检索确认va_end符号存在于libstdc++库中，且尝试将该库加入链接参数后问题未解决，使用的链接命令如下：

usr/bin/gcc -B,asm,/usr/bin -L,ld,/usr/bin -DINCLUDE_HEADER -isystem/usr/include/c++/10 -isystem/usr/include/x86_64-linux-gnu/c++/10 -isystem/usr/include/c++/10/backward -isystem/usr/lib/gcc/x86_64-linux-gnu/10/include -isystem/usr/lib/gcc/x86_64-linux-gnu/10 -isystem/usr/include -isystem/usr/inlcude/x86_64-linux-gnu/ -isystem/usr/local/include -std=c++11 -fPIC  -I/vobs/opensrc/x86_64/boost1580/include -isystem/usr/include/c++/10 -isystem/usr/include/x86_64-linux-gnu/c++/10 -isystem/usr/include/c++/10/backward -isystem/usr/lib/gcc/x86_64-linux-gnu/10/include -isystem/usr/lib/gcc/x86_64-linux-gnu/10 -isystem/usr/include -isystem/usr/inlcude/x86_64-linux-gnu/ -isystem/usr/local/include -std=c++11 -fPIC  -Wl,-rpath-link,/lib/x86_64-linux-gnu -Wl,-rpath-link,/usr/lib/x86_64-linux-gnu/ -L/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux-gnu  -o /home/project/netexec -L/runtime/net /home/project/netexec/bin/cfgfile2.o /home/project/netexec/bin/maincfg2.o /home/project/netexec/bin/snmpcfg.o /home/project/netexec/bin/dynlib.o /home/project/netexec/bin/runtimesupport.o /vobs/magnolia/network/bin/netbase_linux2.o /vobs/magnolia/network/bin/misc_linux2.o /vobs/magnolia/network/bin/notemgr.o /home/project/netexec/bin/cfgfiledefs_linux.o
-Wl,-no-as-needed -ldl -lpthread -lsupc++  -lpq -lpqxx -lbootp -L/home/project/folder2/bin -lInterface -L/vobs/linuxlib/usr/lib64 -lcrypto -lcrypto++  /home/project/netexec/bin/netexec.a

关于为什么生成libInterface.so时未报错，最终链接可执行文件才提示符号缺失 #

• Linux下生成动态链接库（.so）时，链接器默认不会强制校验所有未定义符号，允许.so保留未解析的符号引用，这类符号的解析流程会被延迟到最终链接可执行文件阶段，或是运行时动态加载.so的阶段。只有生成静态库、可执行文件时，链接器默认才会要求所有引用的符号都能找到对应实现。
• 该问题本质是libInterface.so在自身编译链接阶段，没有正确声明对包含va_end实现的库的依赖，将符号解析的责任转移给了下游链接的使用者。

修复方案 #

首先明确当前链接命令存在三个核心问题：

1. 使用gcc命令链接C代码，但未链接完整的C标准库。当前参数仅添加了-lsupc++，这只是libstdc的极小功能子集，va_end的完整实现位于libstdc主库中。
2. 链接参数顺序不符合GCC链接器的工作逻辑：GNU ld对输入参数按从左到右的顺序扫描，依赖库必须放在引用它的目标文件、动态库的后面，否则会出现符号已存在于库中但扫描时被跳过的问题。
3. 额外笔误：命令中-isystem/usr/inlcude/x86_64-linux-gnu/的路径拼写错误，正确应为-isystem/usr/include/x86_64-linux-gnu/，该问题不会触发本次va_end报错，但可能引发其他头文件检索异常。

临时快速修复（无需重新编译libInterface.so） #

对原有链接命令做两处修改即可：

• 将链接命令的前端编译器从gcc替换为g++，g会自动将libstdc等C++程序必需的依赖加入链接参数列表，避免手动漏加。
• 若坚持使用gcc链接，需在整个链接命令的最末尾（即/home/project/netexec/bin/netexec.a之后）添加-lstdc++，保证链接器扫描到libInterface.so的未定义符号后，能后续扫描到libstdc++中的对应实现。

修改后的命令末尾片段示例：

... -lcrypto -lcrypto++  /home/project/netexec/bin/netexec.a -lstdc++

根治方案 #

重新编译生成libInterface.so，从根源解决依赖缺失问题：

• 编译链接libInterface.so时使用g++代替gcc作为前端编译器。
• 链接so阶段添加-Wl,--no-undefined参数，强制链接器在生成so阶段就校验所有未定义符号，避免将符号问题遗留到下游链接环节。
• 链接so时显式添加-lstdc++参数，让so自身的动态依赖列表中包含libstdc++，后续下游程序链接该so时会自动拉取对应依赖，无需手动补加。

内容的提问来源于stack exchange，提问作者sahe