使用 c++11/最近的 g++ 版本 (4.7/4.6) 的可移植性答案

【问题标题】：Portability with using c++11 / recent g++ versions (4.7/4.6)使用 c++11/最近的 g++ 版本 (4.7/4.6) 的可移植性
【发布时间】：2012-10-27 01:09:13
【问题描述】：

我最近一直在使用 g++ 4.6 和 g++ 4.7 开发一个程序。我目前正在利用许多 c++11 功能。

我做出这个决定是因为我可以将库与程序一起捆绑在一个子目录中并使用 LD_LIBRARY_PATH。从那以后，我发现这导致我的程序出现段错误。我可能应该早点测试一下吧。似乎是捆绑的 libc.so.6 导致它（可能是其他的，但绝对是 libc）。

过去我曾在无法安装库的情况下使用这种技术，但它运行良好，但我从来不需要将 libc 和 libstdc++ 与程序一起包含。

有没有办法解决这个问题，还是我必须回滚到旧的 c++ / libc / libstdc++ 版本？（以及随之而来的代码更改的噩梦）

【问题讨论】：

你总是可以静态链接 C++ 库，-static-libstdc++...
我试过这个，但它不起作用。我必须使用需要 dlopen 的函数（例如 getaddrinfo），我还链接到 gnutls，它似乎使用了也无法静态链接的库。生成的二进制文件将 libstdc++ 显示为在 ldd 中动态链接。
如果问题是 libc.so.6 则与 gcc 或 g++ 无关

【解决方案1】：

我会避免依赖LD_LIBRARY_PATH——将其用于测试或开发，而不是生产部署。

改为使用'-Wl,-rpath,$ORIGIN' 链接以创建包含$ORIGIN 的DT_RPATH 标记，这意味着动态链接器将在与可执行文件相同的目录中查找共享库（或例如使用'-Wl,-rpath,$ORIGIN /../lib' 查看../lib)

如果您的程序的任何部分是使用 G++ 4.7 构建的，那么您需要在运行时使用 GCC 4.7 中的 libstdc++.so。

但如果问题出在 libc.so.6 中，则不是 GCC 问题，我的建议是不要尝试捆绑 libc ...尝试替换系统 libc 可能不是一个好主意。

【讨论】：

【解决方案2】：

我会说只使用 g++ 4.6 或 4.7，但不能同时使用两者。还... ldconfig 将尝试使您的程序运行 libc.so 的 /lib 或 /usr/lib 版本，所以如果您有另一个，我不确定它会如何工作。所以也许你应该只使用系统 libc。

如果其他人有任何其他想法，也可以发布。

【讨论】：