如何动态链接到本地副本的libc.so.6，libstdc ++。so.6在系统上与旧版本的gcc [英] how to dynamically link to local copy of libc.so.6, libstdc++.so.6 on system with old version of gcc
问题描述
我的代码是用c ++ 2011编写的，并在g ++ 4.8中编译。但是，我的sysadmin不会从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：version`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使它们可用时，你最终会想要挂钩到官方库中。
对象库有2种形式...。 a（archive）和.so（共享对象）
如果你将它们都复制到同一个人目录，gcc链接器将默认选择.so超过.a。
如果是，设置哪个环境变量[sic]
我认为你不需要担心标准的LIBRARY_PATH或PATH条目，直到你需要交付，或者直到lib64的正式可用。
将你想要的库复制到你自己的目录中，可能
/ home / uname / my_lib64
$ b b
成为
- ... / my_lib64 / libc.so.6
- 。 ../ my_lib64 / libstdc ++。so.6
添加
- -L / home / uname / my_lib64
到你的'final'编译命令，让gcc-linker
并添加
- -lc
- -lstdc ++
到'final'编译命令，让gcc编译器知道lib名称，它应该找到并搜索未解析的符号。
对不起，我无法在我的机器上测试这个。
如果你有麻烦，我似乎记得使用相对路径名（而不是绝对路径）到你的库所在的目录。当我看，似乎是我做的，当时，但可能是一些其他的目标，使相对路径的有用。
我也做了，你可以想要添加一个目标到你的make文件，以确保你正在链接的.a或.so是最新的wrt头文件库，你在代码中包含。我的makefile只是调用一个cp把最新的libs在my_lib64。协调库和标题更新是我期望我的系统管理员做的事情之一，当他们与我的目标合作。
最后...确保标题#include的文件是正确的。要检查，将-H添加到编译，并仔细阅读在每个构建中触发读取的文件名和路径。
我想这将是麻烦做，但你可以使用类似的解决方法到系统管理暴政和复制最新版本标头到您自己的目录。但现在你的工作比我想做的要困难一点。通常，当您安装较新版本的编译器时，它带有对应的标题和库。
祝你好运。
my code is written in c++2011 and compiled in g++ 4.8. however, my sysadmin won't upgrade the compute cluster from gcc/g++ 4.1. i get the following error:
/lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./ManRegOptDes) /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.17' not found (required by ./ManRegOptDes) /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./ManRegOptDes) /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./ManRegOptDes) /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.13' not found (required by ./ManRegOptDes) /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.19' not found (required by ./ManRegOptDes) /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.3' not found (required by /lib/intel/tbb/lib/intel64/gcc4.4/libtbb.so.2)
is it possible to copy the gcc/g++ 4.8 versions of libc.so.6, libstdc++.so.6 to my user directory on the cluster so that my program dynamically links to them? if so, which environment variable(s) to i set so that my executable can dynamically link to them?
thanks.
Can you copy these files?
Yes. The object libraries are normal files like any other. Of course, you will eventually want to hook into the official libraries, when the sysadmin makes them available.
Object Libraries come in 2 forms ... .a (archive) and .so (shared object) If you copy both of them to the same personal directory, the gcc linker will choose the .so over the .a by default.
if so, which environment variable(s) to i set [sic]
I think you need not worry about standard LIBRARY_PATH or PATH entries until you need to deliver, or until the lib64's become 'officially' available. Is it harder to untangle the temporary path modification etc. than to do the following?
Copy the libraries where you want them into your own directory, perhaps
/home/uname/my_lib64
becoming
- .../my_lib64/libc.so.6
- .../my_lib64/libstdc++.so.6
Add
- -L/home/uname/my_lib64
to your 'final' compile command to let the gcc-linker know where it can look for libraries.
and add
- -lc
- -lstdc++
to the 'final' compile command to let the gcc-compiler know what lib names it should find and search for unresolved symbols.
Sorry I can not test this on my machine. If you have trouble, I seem to remember using a relative path name (instead of absolute path) to the directory where your libraries reside. When I look, it seems to be what I did back then, but that may have been some other goal that made relative path's useful.
I also did, and you may want to add a target to your make file to be sure the .a's or .so's you are linking to are up-to-date w.r.t the header libraries you are #including in your code. My makefile simply invoked a cp to put the latest libs in my_lib64. Coordinating library and header updates is one of the things I expect my sys-admin to do, when they are cooperating with my goals.
Finally ... be sure the header files you #include are correct. To check, add -H to your compile, and peruse the file names and paths triggered for read in each build.
I guess that would be messier to do, but you can use a similar work-around to the sys-admin tyranny and copy latest version headers to your own directory. But now you'd be working a little harder than I'd want to do. Typically, when you install a newer version of a compiler, it comes with both headers and libraries that correspond.
Good luck.
这篇关于如何动态链接到本地副本的libc.so.6，libstdc ++。so.6在系统上与旧版本的gcc的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
