That is effectively how Mac OS X handles it as well.
Libraries are linked with a full path name and that name can include placeholders like @loader_path for dlopen'd libraries and @executable_path to find the libraries relative to the current locations of the main executable.
The nice thing is that there is a simple command line tool "otool" that will allow you to set the name and path to the libraries post build so you do not need to worry about passing these things along inside the build environment.
We use these tricks to make the embedded Python.framework inside of Sigil.app fully relocatable since the Sigil.app itself is full relocatable on Mac OS X.
I thought Linux had similar RPATH and name handling capabilities but I am not sure if it works in the same way.
KevinH
Quote:
Originally Posted by chrisridd
Would linking the Linux binaries using -R $ORIGIN/../path/to/my/libraries be a reasonable way of making the Linux binaries self-contained and still movable? Users do not need to mess with the dangerous LD_LIBRARY_PATH environment variable...
Caveat: I've only used $ORIGIN on Solaris with the Solaris linker. I don't know if the Linux linker(s) can handle it. Getting '$ORIGIN' as a string through a build system can be entertaining ;-)
|