Before going on with the post, I’ll give users who’re confused by the post’s title some pointers on how to decipher it: I discussed .la files extensively before, and you can find a description of SONAMEs in another post of mine.
Long- and medium-time Gentoo users most likely remember what happened last time libpng was bumped last year, and will probably worry now that I’m telling them that libpng 1.5 is almost ready to be unmasked (I’m building the reverse dependencies in the tinderbox as we speak to see what breaks). Since I’ve seen through it with the tinderbox, I’m already going to tell you that it’s going to hurt, as a revdep-rebuild call will ask you to rebuild oh-so-many packages due to .la files that, myself, I’ll probably take the chance to move to the hardened compiler and run an emerge -e world just for the kicks.
But why is it this bad? Well, mostly it is the “viral propagation” of dependencies in .la files, which by itself is the reason why .la files are so bad. Since libgtk links to libcairo, and libcairo to libpng, any other library linking with libgtk will be provided with a -lpng entry to link to libpng, no matter whether it uses it or not. Unfortunately, --as-needed does not apply to libtool archives, so they end up overlinking, and only the link editor can drop the unused libraries.
For the sake of example, Evolution does not use libpng directly (the graphic files are managed through GTK’s pixbuf interface), but all of its plugins’ .la files will refer to libpng, which in turn means that revdep-rebuild will pick it up to rebuild it. D’oh!
So what about the visual clue? Well, I’ve decided to use the data from the gold based tinderbox to provide a graph of how many ELF objects actually link to the most common libraries, and how many libtool archives reference them. The data wasn’t easy to extract, mostly because at a first glance, the .la files seemed to be dwarfed by the actually linked objects.. until I remembered that ELF executable can’t have a corresponding .la file.
I’m sorry of some browsers might fail to display the image properly; please upgrade to a decent, modern browser as it’s a simple SVG file. The gnuplot script and the raw data file are also available if you wish to look at them.
The graph corroborates what I’ve been saying before, that the bump of libraries such as libexpat and libpng only is a problem because of overlinking and .la files. Indeed you can see that there are about 500 .la files listing either of the two libraries, when there are fewer than a hundred shared objects referencing them. And for zlib it’s even worse: while there are definitely more shared objects using it (348), there are four times as many .la files listing it as one of the dependencies, for no good reason at all.
A different story applies to GLib and GTK+ themselves: the number of shared objects using them is higher than the number of .la files that list them among their dependencies. I guess the reason here is that a number of their users are built with non-libtool-based build systems, and another good amount of .la files are removed by the less lazy Gentoo packagers (XFCE should be entirely .la free nowadays, and yes, it links to GTK+).
Now it is true that the amount of .la files and ELF files is not proportional to the number of packages installing them (for instance Evolution installs 24 .la files and 69 ELF objects), so you can’t really say much about the number of packages you’d have to rebuild when one of the three “virulent” libraries (libpng, libexpat, libz) is installed, but it should still be clear that marking five hundreds files as broken simply because they list a library that is gone, without their respective binary actually having anything to do with said library, is not the best approach we can have.
Dropping the .la file for libcairo (which is where libgtk picks it up) should probably make it much more resilient to the libpng bumps, which have proven to be the nastiest ones. I hope somebody will step up to do so, sooner or later.
I don’t think some packages installing .la files are simply there because “developers are lazy”.Personally, I don’t have any problem on start cleaning .la files more agressively for Gnome 2.32 (Gnome3 should drop most of .la files already), but this needs to be discussed not only with other Gnome team members (if you worry about Gnome 2.32 still installing .la files, please talk with Nirbheek or Gilles as they know much more than me about this issue… if they agree with dropping .la files, please tell them to mail me directly to start the work as soon I come from holidays as I am currently devaway and with a really limited network access).This is a more general problem, for example, look at:https://bugs.gentoo.org/sho…https://bugs.gentoo.org/sho…This shows that the .la files removal should be discussed probably in mailing list as we mostly agree on dropping them, but we don’t have any plans on when and how to do it and how to fix existing installed .la files that can break due other .la files being removed.Until this is done, we won’t solve .la files problem soon :-(Personally, I am in favor of dropping .la files and, of course, willing to help… but as my knowledge about libtool is really limited, I cannot discuss this myself on mailing list and try to find solutions to problems some people could find.If you want this problem to be solved in the near future (or, at least, sooner than when this will be solved if nothing is discussed), I think you (or any other people with enough knowledge about libtool) should start to discuss this in mailing list to fix this problem finally.Thanks a lot
Pacho, I have discussed, multiple times, on multiple media, a plan to drop most of the .la files at once, starting with Xorg and GNOME at bump time.The problem is that one or two people decided to say “no”, and then nothing came out of it. The end result is now that we’re back at square one, libpng-1.5 will create havoc for the users because .la files weren’t dropped…. with the excuse of not wreaking havoc for the users…
Correct me if I’m wrong, but .la file aren’t needed only for static linking? Couldn’t we just ad an “rm $lafile” after src_install for those packages that will not be statically linked?
Are *.la files needed at all? It’s been Fedora policy for a very long time to delete them, and Fedora seems to get along just fine.About the overlinking caused by *.la files: in libguestfs we added this wrapper around libtool which removes dependency_libs, and this helps:http://git.annexia.org/?p=l…
The @.la@ files are only useful when doing static linking, using libtool, to a library that has further dependencies, without using @pkg-config –static@… which is to say, it is not very useful at all.As for the wrapper… that’s useful to keep @.la@ files around for loading and no static linking, as it makes the only useful point about them moot (keeping track of the static linking dependencies). I’d sooner simply get rid of their generation for non-static, non-module libraries.
I’m still puzzled about why libpng is being linked to gtk+. I have no cairo .la file lying around, nor I have other files (like .pc) that say “link libpng”. I’ve even patched gtk’s makefiles to remove -lpng14 from LDFLAGS but gtk still links to libpng