Re: relinking and buildroots

[roth . gnu]

==> "juhp" == Jens Petersen <address@hidden> writes:

    juhp> Hello, It is a well known problem with libtool (at least in
    juhp> the packaging business!) that relinking breaks things when
    juhp> packages are make install'ed in a buildroot rather than in
    juhp> the final runtime destination.  There seem to be various
    juhp> workarounds and fixes available, but it seems it would be
    juhp> much better if this could be fixed upstream in the libtool
    juhp> distribution itself.

    juhp> The best patch I have come across is the one attributed to
    juhp> maddog in Mandrake's libtool package.  I don't have any
    juhp> problem with the patch, but Alexandre Oliva told me he would
    juhp> prefer an implementation that avoids adding a new prefix
    juhp> (-inst-prefix-dir) to libtool.

    juhp> So any comments please on the above and the patch below?

Another way to do this is to push the solution into the compiler or
linker itself.  In this case, one would replace $CC, $CXX, %__cc,
%__cxx, etc., with a wrapper script that identifies DESTDIR in the
environment and augments the compile-time linker path accordingly.

I'm reluctant to start hacking the libtool driver script, for fear of
breaking the dependency information embedded into the .la files.  This
is particularly important for finicky systems like HPUX, which tend
towards absolute path dependencies.  DESTDIR or build-root installs
are notoriously difficult in this case.

I do agree that the general solution would involve a libtool change.
As long as everyone agrees on something like DESTDIR (which I believe
is the automake convention in any case) then there's no reason why
libtool shouldn't be able to handle it (or at least, facilitate it).
For the time being, though, all of my configure scripts include
hacked-up linker and/or compiler wrappers.

- C