我最近一直在使用 g++ 4.6 和 g++ 4.7 开发一个程序。我目前正在利用许多 c++11 功能。
我做出了这个决定，认为我可以将库与程序一起捆绑在一个子目录中并使用 LD_LIBRARY_PATH。从那以后，我发现这导致我的程序出现段错误。我可能应该早点测试一下吧。似乎是捆绑的 libc.so.6 导致它（可能是其他的，但绝对是 libc）。
在过去，我使用过这种技术，它无法安装库并且运行良好，但我从来不需要在程序中包含 libc 和 libstdc++。
有没有办法解决这个问题，还是我必须回滚到旧的 c++/libc/libstdc++ 版本？（以及随之而来的代码更改的噩梦）
我会避免依赖LD_LIBRARY_PATH——将它用于测试或开发，而不是生产部署。
而是链接'-Wl,-rpath,$ORIGIN'创建一个包含这意味着动态链接器将在与可执行文件相同的目录中查找共享库的DT_RPATH标记（或例如使用'-Wl,-rpath,$ORIGIN/../lib'来查找）$ORIGIN../lib
如果您的程序的任何部分是使用 G++ 4.7 构建的，那么您需要在运行时使用 GCC 4.7 中的 libstdc++.so。
但如果问题出在 libc.so.6 中，则不是 GCC 问题，我的建议是不要尝试捆绑 libc ...尝试替换系统 libc 可能不是一个好主意。
我会说只使用 g++ 4.6 或 4.7，但不能同时使用两者。另外... ldconfig 将尝试让您的程序运行 libc.so 的 /lib 或 /usr/lib 版本，所以如果您有另一个，我不确定它会如何工作。所以也许你应该只使用系统 libc。
如果其他人有任何其他想法，也可以发布。