未关联libstdc++的C++ .so文件为何运行表现存在差异？

咱们把这个问题拆解透，你遇到的现象本质是gcc编译C代码时不会自动链接libstdc，再结合动态链接的符号解析规则共同导致的。

1. gcc与g编译C代码的核心差异 #

你用gcc -fPIC --shared foo.cpp -o libfoo.so编译foo.cpp时，gcc默认会把.cpp文件当作C代码处理（哪怕后缀是cpp），它不会自动帮你链接C++标准库libstdc++.so。这就导致生成的libfoo.so里，std::cout和std::endl对应的符号（比如你看到的_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_）都是未定义状态。你可以用下面的命令验证：

nm -D libfoo.so | grep _ZSt4endl

输出会显示U _ZSt4endl...，其中U代表该符号未被解析，需要在程序运行时从其他已加载的库中寻找。

而如果用g编译foo.cpp，g会自动添加-lstdc++参数链接标准库，此时libfoo.so会明确依赖libstdc++.so，符号会被正确关联。

2. 动态链接的符号解析时机与规则 #

动态库的符号解析是在进程加载阶段完成的：

• 当main.cpp没有引入<iostream>时，编译出的main程序本身不依赖libstdc++.so。启动main后，系统会加载libbar.so，接着libbar.so加载libfoo.so，但此时整个进程空间里都没有加载libstdc++.so，libfoo.so里的std::endl找不到对应的符号，就会抛出你看到的错误。
• 当main.cpp引入<iostream>后，main程序会直接依赖libstdc++.so，启动时系统会先把libstdc++.so加载进进程空间。之后再加载libfoo.so时，它需要的std::endl符号已经在已加载的libstdc++.so中存在，所以能正常解析，程序运行无问题。

3. 为什么编译libbar.so时加了-lfoo也没用？ #

你编译libbar.so时加了-lfoo，这只是告诉链接器libbar.so依赖libfoo.so，但并不会帮libfoo.so补全它自身缺失的依赖。libfoo.so本身没链接libstdc++的问题，不会因为被其他库链接就自动修复。

总结 #

gcc并非不能编译C代码，但它不会自动处理C标准库的链接逻辑。所以编译C代码（哪怕是生成动态库），都应该用g，它会自动帮你处理libstdc++的依赖，避免这种运行时符号缺失的坑。

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