I recently learned that the linkers of Sun, IRIX and GNU can do relative linking from the binary they are invoked with using the '$ORIGIN' macro in rpath (-rpath or -R option).
What does this mean? Well, in prefix our libraries are in a non-standard location: somewhere in your prefix. In order for the runtime linker to find them while executing your program, we make sure we embed "hints" in each binary where it can find the libraries it looks for. These "hints" consist of absolute (full) paths to the lib dirs in the prefix. So far, so good. However, suppose for some reason your prefix location would change: a new home directory, remote access through a network which has a different path... etc. In such case the applications won't work. This is not a "bug" of prefix, this is in general for every application that uses a shared library. The '$ORIGIN' macro could solve this, as it figures out at runtime where the binary is located, and replaces that for '$ORIGIN'. I quickly looked at if I could easily switch this on, but unfortunately it's not that simple, IMO: we don't know where the library is located in the prefix. Because of this, I also don't know how to find the lib dirs, i.e. '$ORIGIN/../lib'. So if anyone has thoughts on this... It would be cool if we could make binary packages for an arbitrary prefix offset, wouldn't it? Might even make the bootstrap phase a bit less painful (sort of stage3). A secondary issue that came out of this is, why do we install in /usr in prefix actually? I think for no particular reason, other then that portage is designed to work like that. (I can live with that.) -- Fabian Groffen Gentoo on a different level -- [EMAIL PROTECTED] mailing list
