Reputation: 35657
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.
Upvotes: 2
Views: 3663
Reputation: 213375
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.
Upvotes: 1
Reputation: 371
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?
Upvotes: 3