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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
