On Thu, 2006-09-21 at 19:19 +0200, Anders Johansson wrote:
On Thu, 2006-09-21 at 08:23 +0200, Roger Oberholtzer wrote:
On Wed, 2006-09-20 at 22:59 +0200, Anders Johansson wrote:
I am confused. LD_RUN_PATH is used during compilation, not during execution, as far as I'm aware. The runtime version is LD_LIBRARY_PATH
LD_RUN_PATH results in information being added to the built executable that will tell it where to look for libs at runtime, independent of any places told at runtime. It becomes part of the binary. Hence the 'RUN' in the name.
LD_LIBRARY_PATH is something you can set in the runtime environment that also tells where to look for libraries. It had nothing to do with compilation.
I'm not entirely sure why you felt you had to repeat what I said, but the point of my email was: why not create a wrapper script for your application that does
You are splitting hairs. You said LD_RUN_PATH is not used during execution. I think that is a misleading statement, The information it provides during compilation IS used during execution. Of course, setting it after compilation has no effect.
export LD_LIBRARY_PATH=/path/to/your/library
and then executes the application that needs the special lib
This seems like a much nicer solution than to add extra directories to ld.so.conf for one particular app (and it beats the living daylights out
I cannot realistically wrap the applications in the offending package. Unless it is in some complicated and doomed to fail method, like an update from the packager that wipes out the modifications. So LD_LIBRARY_PATH would need to be a global setting, resulting in the same effect as ldconfig. I think my best bet is to see if I can remove the odd libraries and see if the package's apps will use the system one. I think the system one has more things enabled. -- Roger Oberholtzer