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!?!

1 Answer 1


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. Commented Jun 10, 2016 at 16:58
  • @KyleEnglish I updated my answer Commented Jun 10, 2016 at 17:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .