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