Delivery of libstdc ++. So.6 with the app

Question

I want to use gcc 4.8.1 for my application (requires libstdC ++. So.6.0.18), however clients only have libstdC ++. so.6.0.13. I used -static-libgcc -static-stdlibc++ for a while, but my application consists of several dynamically linked libraries and one main application. This means that when compiling each dynamic library, they must statically compile a standard library that is redundant and wasteful. I just want to send the standard library of my choice with my product, however every time I run my application in an environment like them, it always loads the wrong standard library. He prefers the version of /usr/lib64/ no matter what I seem to be doing (it seems to take precedence over LD_LIBRARY_PATH ).

Limitations:

• I can not get them to switch to the new standard library.

• I do not want to create dynamic libraries statically. (I could statically compile everything into the main application once, but there are some logistical barriers that prevent me from recompiling some libraries into static ones).

-Wl,-rpath=$(path_to_directory) is a bit dangerous, however it is legal because clients have some settings that allow me to set path variables. However, setting the rpath of my new stdlibC ++ does not seem to override the default /usr/lib64 version. I am still getting GLIBCXX errors because it will not use the correct library.

Is there really an elegant solution for this?

Perhaps there is only an error in my procedure. Here is an example (sorry for censorship, but it's just a username):

 ~/example$ pwd /home/username/example ~/example$ echo $LD_LIBRARY_PATH ~/example$ ls Makefile libstdc++.so.6.0.18 test.cpp ~/example$ make g++ -std=c++11 -Wall -Werror test.cpp -o test ~/example$ ldd test ./test: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by ./test) linux-vdso.so.1 => (0x00007fffe5919000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x000000390b800000) libm.so.6 => /lib64/libm.so.6 (0x0000003904800000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000000390b400000) libc.so.6 => /lib64/libc.so.6 (0x0000003904400000) /lib64/ld-linux-x86-64.so.2 (0x0000003904000000) ~/example$ setenv LD_LIBRARY_PATH /home/username/example ~/example$ echo $LD_LIBRARY_PATH /home/username/example ~/example$ ldd test ./test: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by ./test) linux-vdso.so.1 => (0x00007fff2d3ff000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x000000390b800000) libm.so.6 => /lib64/libm.so.6 (0x0000003904800000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000000390b400000) libc.so.6 => /lib64/libc.so.6 (0x0000003904400000) /lib64/ld-linux-x86-64.so.2 (0x0000003904000000) 

Sorry guys, I made a pretty dumb mistake ...

 ~/example$ file libstdc++.so.6.0.18 libstdc++.so.6.0.18: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped 

Some dweeb created the wrong version of the library, while another dweeb (namely me) tried to use it on a 64-bit machine. Using LD_LIBRARY_PATH worked all the time ...

Answer 1

Your problem is that the executable is associated with the sound libstdc++.so.6 not with the full library name of the library libstdc++.so.6.0.16 . The dynamic linker will look for libstdc++.so.6 in common places (i.e. LD_LIBRARY_PATH, DT_RPATH, ldconfig dirs, etc.), so to provide version 6.0.18 you will need a symbolic link called libstdc++.so.6 , indicating on her.

Instead of using LD_LIBRARY_PATH (which is fragile on computers that you do not control because users can change their environment), I prefer to associate with '-Wl,-rpath,$ORIGIN' (NB, quotation marks are needed to stop the shell extension $ORIGIN )

RPATH $ORIGIN tells the dynamic linker to start looking for shared libraries in the same directory as the executable, so if you send libstdC ++ so that it will be found with your executable. If you want to send the executable to the bin directory and have the library in the lib directory, you can use '-Wl,-rpath,$ORIGIN/../lib' or other paths relative to the location of the executable.