我的代码是用c ++ 2011编写的，并且是用g ++ 4.8编译的。但是，我的系统管理员不会从gcc / g ++ 4.1升级计算群集。我收到以下错误：
/lib64/libc.so.6：找不到版本“ GLIBC_2.14”（./ ManRegOptDes必需）/usr/lib64/libstdc++.so.6：找不到 版本“ GLIBCXX_3.4.17”（../ ManRegOptDes必需） /usr/lib64/libstdc++.so.6：找不到 版本“ GLIBCXX_3.4.11”（./ ManRegOptDes必需）/usr/lib64/libstdc++.so.6：找不到版本“ GLIBCXX_3.4.9”（../必需ManRegOptDes）/usr/lib64/libstdc++.so.6 ：找不到版本'GLIBCXX_3.4.13'（./ManRegOptDes必需）/ usr / lib64 / libstdc ++。so.6 ：找不到版本'GLIBCXX_3.4.19'（由./ManRegOptDes）/usr/lib64/libstdc++.so.6 ：找不到版本'CXXABI_1.3.3'（/lib/intel/tbb/lib/intel64/gcc4.4/libtbb.so.2要求）
是否可以将libc.so.6，libstdc ++。so.6的gcc / g ++ 4.8版本复制到群集上的用户目录中，以便我的程序动态链接到它们？如果是这样，我要设置哪个环境变量，以便我的可执行文件可以动态链接到它们？
谢谢。
可以复制这些文件吗？
是的。对象库是普通文件，就像其他任何文件一样。当然，当sysadmin使它们可用时，您最终将希望挂接到正式库中。
对象库有两种格式：.a（存档）和.so（共享对象）。如果将它们都复制到同一个人目录，则默认情况下，gcc链接程序将选择.so而不是.a。
如果是这样，我要设置哪个环境变量[sic]
我认为您不必担心标准的LIBRARY_PATH或PATH条目，直到您需要传递它，或者直到lib64成为“正式”可用为止。与执行以下操作相比，解开临时路径修改等是否更难？
将所需的库复制到自己的目录中，也许
/home/uname/my_lib64
变得
添加
到您的“最终”编译命令，以使gcc-linker知道可以在哪里查找库。
并添加
到'final'编译命令，以让gcc编译器知道应找到的库名称，并搜索未解析的符号。
抱歉，我无法在我的机器上对此进行测试。如果遇到问题，我似乎记得使用了一个相对路径名（而不是绝对路径）到您的库所在的目录。当我看时，这似乎是我当时所做的，但这可能是使相对路径有用的其他一些目标。
我也这样做了，您可能想要向目标文件中添加一个目标，以确保链接到的.a或.so是最新的#w包含代码中的标头库。我的makefile只是调用了一个cp来将最新的库放入my_lib64中。当他们与我的目标合作时，协调库和标头更新是我希望系统管理员执行的操作之一。
最后...确保#include的头文件正确。要进行检查，请在编译中添加-H，并仔细阅读每个版本中触发读取的文件名和路径。
我想这样做会比较麻烦，但是您可以使用与sys-admin专制类似的解决方法，并将最新版本的标头复制到您自己的目录中。但是现在您的工作要比我想做的要辛苦一些。通常，当您安装较新版本的编译器时，它附带有相应的头文件和库。
祝你好运。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句