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