how to dynamically link to local copy of libc.so.6, libstdc++.so.6 on system with old version of gcc

c++, c++11, g++, gcc

Solution

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.

Problem

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.

Original source