==> "juhp" == Jens Petersen <[EMAIL PROTECTED]> 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
_______________________________________________
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
