On Fri, Oct 10, 2008 at 3:39 PM, Kevin Kofler <kevin.kofler@xxxxxxxxx> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
