Re: rpath reduction (was: another 1.5 release?)

[Daniel Reed]

On 2005-01-28T22:03+0100, Ralf Wildenhues wrote:
) I hoped I could write it so that it would also work in case of DESTDIR
) installs, where we might not know the directory structure in advance.

Situations to mind:

buildh:~> ./configure --prefix=/usr && make install 
DESTDIR=/var/tmp/buildroot-12345
buildh:~> (cd /var/tmp/buildroot-12345; tar cf - .) | krsh client.example.com 
'(cd /; tar xvvf -)'

Libtool believes the software will eventually live in /usr (as it will) but
is temporarily being placed in /var/tmp/buildroot-12345. The software is
then moved out of /var/tmp/buildroot-12345 outside of Libtool's view.


buildh:~> ./configure --prefix=/usr && make install 
DESTDIR=/afs/example.com/live
client:~> mount --bind /afs/example.com/live/usr /usr
  aka
buildh:~> ./configure --prefix=/usr && make install
client:~> mount buildh.example.com:/usr /buildh/usr
client:~> mount --bind /buildh/usr /usr

Libtool believes the software will eventually live in /usr (as it will) but
is temporarily being placed in /afs/example.com/live/usr (which isn't really
the case; putting it in /afs/example.com/live/usr is how it ends up being in
/usr on the client).

These two situations are similar in that Libtool doesn't really know how the
software that's installed into a DESTDIR actually makes it to the final
prefix. The key difference, however, is that in the former, the DESTDIR path
is no longer valid (it is, in fact, never valid on client), where in the
latter, DESTDIR/prefix and prefix are always valid, even after final
installation on client.

Additionally, in the former, existing hierarchy on the client that does not
exist on the buildh can cause big problems. It is in this situation that the
/path/to/gcc -> /path/opt/gcc problems can happen (such a symlink on buildh
could cause an rpath to be incorrectly removed, or such a symlink on client
could cause a needless rpath).



buildh:~> ./configure --prefix=/afs/example.com/live/usr && make install
client:~> mount --bind /afs/example.com/live/usr /usr
  aka
buildh:~> ln -s / /buildh
buildh:~> ./configure --prefix=/buildh/usr && make install
client:~> mount buildh.example.com:/usr /buildh/usr
client:~> mount --bind /buildh/usr /usr


buildh:~> ./configure --prefix=/afs/example.com/live/usr && make install
client:~> PATH="${PATH}:/afs/example.com/live/usr/bin"
  aka
buildh:~> ./configure --prefix=/usr && make install
client:~> mount buildh.example.com:/usr /buildh/usr
client:~> PATH="${PATH}:/buildh/usr/bin"

In both, Libtool believes the software will eventually live in
/afs/example.com/live/usr or /buildh/usr (as it will).


It seems that Libtool, as used today, might not make the best authority on
what paths can and can't be eliminated, as too much knowledge necessary for
the final decision just is not available to Libtool. It might make sense to
have a libtool --mode=strip_rpath or something that can be called in the
first case above, to reduce rpaths in a binary after it's been installed in
its final place, but in any of the other situations there just does not seem
to be an appropriate way

-- 
Daniel Reed <address@hidden>    http://people.redhat.com/djr/   
http://naim.n.ml.org/
A democracy is a sheep and two wolves deciding on what to have for
lunch. Freedom is a well armed sheep contesting the results of the
decision. -- Benjamin Franklin