0

I've read a lot of guidance that says the LD_LIBRARY_PATH is searched before anything else, but one of my .so libraries is linking with libtdc++.so.6 in /usr/lib64.

ldd mylib.so:
...
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f82abd18000)
...

I want mylib.so to link with libstdc++.so.6 in another location, like /apps/gcc_4.8.0/lib/libstdc++.so.6

So I add /apps/gcc_4.8.0/lib to LD_LIBRARY_PATH, which does not have /usr/lib64 in it, but it still doesn't find it there.

If I add:

setenv LD_PRELOAD /apps/gcc_4.8.0/lib/libstdc++.so.6

to my environment, there are no more linker errors. Yay, but that doesn't solve the problem. Users downstream aren't going to want to depend on this library being in the proper place. WHY ISN"T LD_LIBRARY_PATH BEING SEARCHED FIRST!?!

0

It should work with the Wl,--rpath=/apps/gcc_4.8.0/lib/libstdc++.so.6 compiler switch.

Update: If you need also the new loader use this compiler switch: -Wl,--dynamic-linker=<path-to-the-new-dynamic-linker>

  • Unfortunately that did not work for me. I continue to get the runtime error, and the linker (or maybe the loader?) continues to look in /urs/lib64. Only the LD_PRELOAD has worked so far. – KyleEnglish Jun 10 '16 at 16:58
  • @KyleEnglish I updated my answer – Al Bundy Jun 10 '16 at 17:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.