Re: libtool relink bug/fix?

[Wesley W. Terpstra]

On Wed, Apr 09, 2003 at 09:33:55AM -0400, David A. Desrosiers wrote:
>       I found your thread on the libtool relink bugs at:
> 
> http://mail.gnu.org/archive/html/libtool-patches/2000-10/msg00030.html
> 
>       I'm curious to know if you have any insight into the issue, since, 2
> years later, the issue still isn't fixed in the latest libtool (1.4.3-7 in
> Debian). The issue I'm having (with one of my projects, pilot-link) is that
> the relink command produces the following:
>
> <snip standard failure to link in a staged install>

My patch to correct this from way back then was rejected because it could
not work on all platforms. The problem is some OSes, forget which, have no
distinction between runtime library search path and linktime search path.
This means you have to link against the final location or else have a broken
runtime search-path. Because the libtool script tries to provide a
lowest-common-denominator API, they rejected a fix.

That said, I consider this complete nonsense. Not all platforms need staged
installs. Those which do need staged installs have this distinction.

>       I can't seem to get around it, unless I manually hack the relink out
> of the .la file itself. Have you any insight?

Well, you could try porting my old patch:
        http://mail.gnu.org/archive/html/libtool-patches/2000-10/bin00004.bin
... but, it doesn't address issues on non-linux/bsd platforms.

Because of this, I think your best bet is to sed the .la file.

I know this is awful, but for some reason the libtool maintainers have never
put a priority on properly addressing this issue. It would need a concerted
effort of each port maintainer. However, as it stands, libtool is not
capable of handling staged installs of inter-library depends. Which makes it
unusable (without hacking) for most major debian/redhat packages.

I hope that some day they will get around to fixing this.
The primary users of libtool are linux/bsd, so they should strive to make
at least these systems work properly.

Despite this issue, I still think libtool is quite useful. However, I think
the focus on lowest-common-denominator without being able to address the
needs of the packaging systems of supported platforms is just silly. Yes,
libtool must support a portable API for the upstream maintainers. However,
it should still allow packagers for specific platforms to do their job.

Finally, another option I have sometimes considered is to extend fakeroot to
make everything created outside of the source directory remap to inside
debian/tmp. If this were done, then debian would no longer need the DESTDIR
option on install. Further, then libtool would believe that it had installed
to the final destination, thus relinking properly. I will move this topic to
debian-devel.

---
Wes