Ryan Schmidt wrote:
Hi, Jann. Thanks for your reply.
On Mar 11, 2007, at 05:38, Jann Röder wrote:
There are two solutions for your library problem: 1. Export DYLD_LIBRARY_PATH before launching the software, so that the linker knows where to find the libraries
Do you mean: export DYLD_LIBRARY_PATH while compiling the other software, so it knows where to find its dependencies, and then everything will work normally when running the software later, or do you mean to export the variable in order to actually run the software later? If the latter, that won't do. I don't want to affect how end users use the software. I just want the build system to not require root access.
When building the software, the linker saves the path of the library it linked against in the binary. When the software is later run, the linker looks in that place first, if that doesn't work out it looks in the directories specified by DYLD_LIBRARY_PATH, and if that doesn't work it looks in the default locations (/lib, /usr/lib, ... ). So if you use that approach your users need to have DYLD_LIBRARY_PATH defined in order to run the software, but if you want to make it a double-clickabale application like theGimp.app you will have to do that anyway in some script. Sorry for being unprecise in my previous mail. I meant that the loader knows where to find the libraries, not the linker.
2. When building the libraries pass -install_name ${prefix}/lib/$outfile to the linker. ${prefix}/lib/$outfile is the final installation destination of the library. This approach requires patching the makefile.
That sounds like a lot more work. Especially since you mention a specific outfile, but I don't know which files these packages install. Many packages install dozens of files, in lib, in include, in share, and so on. I don't want to have to figure out for each package which files it installs.
Well usually the Makefile has a variable that spciefies how the linker is called. So it usually suffices to change that variable. Make will replace $outfile with the library it is currently building. This is the approach I used in one of my portfiles. The port built a dynamic library and then built a binary that linked against it. After installing the files in ${prefix} the binary couldn't find the library anymore, because the hardcoded path still pointed to the destroot destination, and the new library location (/opt/local/lib) wasn't specified in DYLD_LIBRARY_PATH. By giving the -install_name flag to the linker, you can change the path that is hardcoded in the binary when linking against the library.
Do you have any comment on whether or not my chroot idea could work? That's probably the solution I will try, unless anyone else has suggestions.
I have no experience with chroot, but I think it might work. Good luck. Jann