The sheer amount of articles regarding libtool archives in my blog’s archive is probably enough to tell that I have a pretty bad relationship with them. But even though I have been quiet, lately, I haven’t stopped working on them.
In particular, my current “daily job”, or at least one of them, has among its task the one of getting more reliable cross-compilation support with Gentoo’s ebuilds, and dropping the cursed .la files is part of the plan. With them around, often enough, -L/usr/lib64 is added to the linking line, which causes all sorts of troubles once it’s resolved to a fully qualified path such as /usr/lib64/libfoo.so which cannot obviously be linked against.
After a bit of doubts on how to proceed (waiting for Gentoo proper to remove all of them, given the kind of obstruction I find coming from developers, was not really an option), it was decided to try building the whole chroot used for cross-compilation, and the cross-compiled roots by removing all the .la files with the exclusion of the one that is known to be required (libltdl.la).
For those wondering, it was achieved with this “simple” setting in make.conf:
INSTALL_MASK="
/usr/lib/lib[0-9]*.la
/usr/lib/lib[a-k]*.la
/usr/lib/lib[m-z]*.la
/usr/lib/libl[0-9]*.la
/usr/lib/libl[a-s]*.la
/usr/lib/libl[u-z]*.la
/usr/lib/liblt[0-9]*.la
/usr/lib/liblt[a-c]*.la
/usr/lib/liblt[e-z]*.la
/usr/lib/libltd[0-9]*.la
/usr/lib/libltd[a-k]*.la
/usr/lib/libltd[m-z]*.la
/usr/lib/libltdl[0-9]*.la
/usr/lib/libltdl[a-z]*.la
"
At this point, my opinion has always been that there would be no problem with building further packages even though the libtool archives were gone… turns out I was mostly, but not entirely, right. Indeed if the system were built using the standard GNU ld linker, there would have been no package failure; on the other hand, all of this is built using gold – which is much stricter about underlinking – and that makes a huge difference.
Not only the use of libtool by itself would make it mostly pointless to use --as-needed, but it also makes --no-add-needed (the feature that makes the linker strict in terms of underlinking) much less effective: if you only link to libfoo.la, which in turn lists -lbar, and you use symbols from both, the libtool archive would provide both to the linker, hiding the fact that you didn’t express your dependencies properly.
But out of a whole operating system built without .la files, how many packages did require fixes? The answer is two: libsoup (which was actually already fixed in the second-to-last release, so the fix was simply updating the version used) and tpm-tools (that, similarly to trousers and opencryptoki has a quite bogus build system).
I’m not saying that they would be the only packages suffering from these issues, and in particular, with the fact that this system is not building anything statically, it is likely to encounter much fewer complications, but it is more than likely that with minimal effort we’d suffer fewer problems with linking, rebuilds, and dependencies if we were to drop those files entirely, and switch to fixing the few packages failing.
I’m still confused about what I should be advising people who are intentionally using static libraries. I undertand that, as a distribution, Gentoo should always use shared libraries wherever possible and hence the libtool archives are not needed there but what about situations like http://code.google.com/p/le… ? I know you’ve suggested pkg-config to me before and I thought about mentioning that but I don’t think I want to force OS X users to install it. I notice that the latest version of libtiff now always installs a pkg-config file but only installs a libtool archive when installing the static library.
I have INSTALL_MASK=”*.la”, and then an env file for the following packages to allow .la files for them:imagemagick, gst-plugins-base, gnome-bluetooth, libtoolAnd all is working well, I only have 17 .la in /usr/lib and a fully working gnome desktop.
Thank you Diego. I always admire your pedantic work. It might look not important and nobody seems care much about, but it is a root of many problems.@Damien, could you post your env file?
As with Damien, I’m using INSTALL_MASK=”*.la” (actually, PKG_INSTALL_MASK as I use FEATURES=buildpkg as well and don’t want them in the packages, either, see the make.conf (5) manpage).The only exception I have is an env file as well, but the way it’s setup here it’d be one such file per exception package. However, I only have one such exception package, libtool itself.cat /etc/portage/env/sys-devel/libtool PKG_INSTALL_MASK=So all it does is unset the general setting for that single package.But I’m not doing cross-compiling, tho I do have a 32-bit chroot that’s a full build-image for my 32-bit netbook, with the same settings for its portage as well. Nor am I using gold.I set that some months ago and did a full –emptytree rebuild to get rid of them all and verify it worked (it did, with the one exception) based on Diego’s posts. =:^)
I’m more gnarly than you, I’m using INSTALL_MASK=“*.la” and “–disable-static” (to avoid building .a files) forced everywhere for over 2 years now (desktop and server installations); at the moment I have found only 1 (ONE) package that doesn’t compile: VirtualBox’s kernel modules. To be more precise, it’s not a compilation issue, is more a bogus test of the configure phase that checks for *.a from gcc instead of the corresponding .h header files. VirtualBox’s module apart, I never had problems of any sort with a my desktops (KDE4 + Gnome + XFce4) or servers (Gentoo Hardened); compilations are faster, backups are shorter and revdep-rebuild has never been used to fix ABI changes.
I have had a lot more trouble removing all .la files; many programs with plugins have issues without .la files. An example which I remember in the moment is emilia-pinball.The solution which I use which I read somewhere is to remove only those .la files which contain the line
shouldnotlink=noBut even with this solution, some packages gave trouble: The .la files in libsidplay and gst-plugins-base must also not be removed.The latter is clear: It installs the .la files needed to compile all other gst-plugins.Maybe some of these issues have been fixed meanwhile – last time I checked was perhaps one year ago.I did the same as Damian an Duncan for my amd64 laptop gentoo. The exceptions on my system are libtool, gstreamer, some gst-plugins and webkit-gtk