问题
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.
回答1:
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.
回答2:
It depends on what your "cluster" allows. If you have access to you home directory on these machines, you might be able to use the environment LD_LIBRARY_PATH to locate the relevant libraries.
回答3:
Check out man ld.so for the full details. LD_LIBRARY_PATH works a lot like $PATH does but for libraries. LD_LIBRARY_PATH=/home/user/libraries:/home/user/math_libs:$LD_LIBRARY_PATH may be all you need once you copy the old libraries over.
But then you likely need ALL of the old libraries because the new ones will use the newer libc/c++ The problem is older libc were also meant to use a different Linux kernel too. So you might get weird results due to syscalls not matching up.
回答4:
Use Redhat errata and read with attention compatibility and requirements for your latest libraries. It is a big list of checks you need to follow. No short answer will be correct.
As example I just upgraded a few different server of Redhat 6.6 and 6.3 / 6.2 / 6.1 to same version of glibc and stdc++ libraries required by compiler g++ 4.4.7.
Your best option to do system level deployment of what Redhat needed. For Redhat 5 to use newer 4.8 compiler libraries.. -- I strongly recommend from experience - forget it !
来源：https://stackoverflow.com/questions/21056646/how-to-dynamically-link-to-local-copy-of-libc-so-6-libstdc-so-6-on-system-wit