Per shared object rpath

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

Hi all,
after thinking a bit about the linker issues in the ports tree (mostly
missing rpaths in libraries) I think having better location support
for shared objects is a must-have item for the package support.

Being able to map all libraries into /proc/lib or where ever using
the VFS environments would work, but has the consequence of addings
other head aches. E.g. all these mappings will need some kind of
kernel space to store, it will increase the variation in the filesystem
view of different processes (one reason I don't really like /proc for),
etc. IMO the ideal solution is to use VFS environments only when
necessary. The most important use for VFS environments is the package
building itself since it saves us from building a chroot environment
for most builds (to correctly hide unwanted installed packages).

For the installed system the most important dependency is that for a
shared object. The critical situation arises as soon as multiple
versions of one library are installed and another library depending
on the first one is needed by programs linked against multiple versions
of the former. Back in my Linux days there was the major version change
from libpng 1.0 to 1.2. Having a self compiled system lots of diffuculties
arised. E.g. QT and GTK link against libpng and depending on the installed
version and those present at compile time things utterly failed. 

This situation isn't well handled by any package system I am aware off.
It is somewhat possible to do it manually e.g. under NetBSD if you
copy/symlink all libraries needed by a program linked against the old
version to one location and altering the rpath accordingly. Situation
will be bad if there multiple such libs and in the worst case you end
up with a copy/symlink of each library for each program. Now in practise
the situation is not nearly such bad.