WDef

Group: Members
Posts: 798
Joined: Sep. 2005 |
 |
Posted: Sep. 14 2007,16:40 |
 |
Jumping back in the thread a bit.Quote | It seems that some applications (eg the ones in the hplip extension I'm working on) seem to know that if they start in /opt/app/bin, the libs will be in /opt/app/lib. Other applications (eg the ones in samba.dsl) seem to resist all attempts to tell them where to find libs... |
This has to do with the -rpath compiler flag which hard codes the locations of libraries (RPATH) into the headers of the resulting binary. If that was set then it cannot be overriden by LD_LIBRARY_PATH at runtime.
I've sometimes achieved this (I think) by doing:
Code Sample | export PREFIX=/opt/app env LD_LIBRARY_PATH=${PREFIX}/lib LD_RUN_PATH=${LD_LIBRARY_PATH} ./configure make |
When it works (only sometimes, the build has to recognize the LD_RUN_PATH variable ), you won't have to use a wrapper so the binary can find the libs in /opt/app/lib
Compiled programs that seemingly "know" where the libs are probably used libtool during the compile or otherwise had -rpath set. I think libtool automatically hard codes the location of the libs (or used to).
People that know about things like hacking Makefiles could always try setting the -rpath and related flags manually I suppose.
One way to avoid all of this is to compile with static linking of course, the downside is a bigger binary and perhaps slower performance.
|