On Fri, Oct 10, 2008 at 3:39 PM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
* Libtool generates .la files even on platforms which don't need them. It's
ridiculous that we still have to delete unwanted files in almost all packages,
and even more so that they have a comment on the top saying "DON'T DELETE THIS
FILE!".
(That said, CMake has a similar dependency tracking feature which, when
enabled, is similarly broken by default. A package has to either not use
dependency tracking at all (which may cause problems on some
platforms/configurations, e.g. static libraries) or use an extra command to do
the right thing (only linking in indirect deps explicitly if the platform
requires it). But at least it's possible, unlike libtool where you have to
manually delete a file which screams not to be deleted.)
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.
- 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.
* 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'.
--
Dan