Ignore LD_LIBRARY_PATH and stick with library given through -rpath at link time

Question

I'm sitting in an environment which I have no real control over (it's not just me, so basically, I can't change the environment or it won't work for anyone else), the only thing I can affect is how the binary is built.

My problem is, the environment specifies an LD_LIBRARY_PATH containing a libstdc++ which is not compatible with the compiler being used. I tried compiling it statically, but that doesn't seem possible for g++ (version 4.2.3, seems to have been work done in this direction in later versions though which are not available, -static-libstdc++ or something like that).

Now I've arrived at using rpath to bake the absolute path name into the executable (would work, all machines it's supposed to run on are identical). Unfortunately it appears as though LD_LIBRARY_PATH takes precedence over rpath (resetting LD_LIBRARY_PATH confirmed that it's able to find the library, but as stated above, LD_LIBRARY_PATH will be set for everyone, and I cannot change that).

Is there any way I can make rpath take precedence over LD_LIBRARY_PATH, or are there any other possible solutions to my problem? Note that I'm talking about dynamic linking at runtime, I am able to control the command line at compile and link time.

Thanks.

Answer 1

Maybe you can use a shell wrapper which modifies the environment for just this program?

#!/bin/sh

LD_LIBRARY_PATH="/path/to/your/lib:${LD_LIBRARY_PATH}"
export LD_LIBRARY_PATH
exec /path/to/binary $@

This should overload the LD_LIBRARY_PATH before execution and then replace the wrapper with your binary via exec.

Would this help?

Answer 2

Linking against libstdc++.a is definitely possible, albeit tricky. Instructions here.

I am a bit skeptical of your claim that LD_LIBRARY_PATH takes precedence over the "baked in" DT_RPATH though -- at least on Linux and (I believe) Solaris, LD_LIBRARY_PATH is only looked at after DT_RPATH lookup has failed.