libtool annoyances (was: Re: CMake!)

[Kevin Kofler]

Dan Nicholson <dbn.lists <at> gmail.com> writes:
> The reason why the .la file is forced to be installed is because it's
> needed to support `make uninstall'. Last I saw, the libtool developers
> were considering allowing you to opt out of that situation. It's
> certainly come up before, and there should be a way to avoid this.

Indeed, I'm glad you folks are aware there's a problem and trying to fix it.

> > - checking that the Fortran and Java-to-native-code compilers exist (even
> > in an all-C/C++ project).
> 
> libtool-2.2 doesn't do that anymore.

And that's good news, one less annoyance, thanks for that!

> > * Libtool thinks /usr/lib64 needs an RPATH, unless you use a Fedora-patched
> > version, in which case it'll think /usr/lib needs an RPATH on x86_64 even 
> > on a Debian system. So, unless you're about to hack the generated/copied 
> > libtool scripts manually, there's no way (using libtool) to make a package 
> > which will generate no bogus RPATHs on x86_64 on at least one distro.
> 
> Are you sure about that? Last time I looked (and I did look, because I
> was trying to emulate libtool's rpath functionality for mesa), libtool
> asks gcc for the system library directories by looking at `gcc
> -print-search-dirs'. In libtool-2.2, it also takes into consideration
> `gcc -print-multi-os-directory'.

It may have been a bug, but what I described is exactly what Romain Liévin and 
I experienced with the tilibs (the libti* stuff at http://svn.tilp.info/ ): if 
Romain autotooled the project on Debian, I ended up with rpaths on Fedora 
x86_64, if I autotooled it on Fedora, he ended up with rpaths on Debian x86_64.

If libtool 2.2 does the right thing there, that's indeed good news.

        Kevin Kofler