Homegrown destroot, maybe chroot?

[Jann Röder]

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