I’m not sure if I went to a large extent writing about this before, but I probably should try to write about it here again, because, once again, it helps removing some useless
.la files from packages (and again, this is just something done right, not something I’m pulling out of thin air; if you think I’m pulling it out of thin air, you have no clue about libtool to begin with — and I’m not referring to leio’s complains, that’s another topic entirely).
Shared objects are, generally, a good thing because they allow different programs to share the same code in memory; this is why we consider shared libraries better than the static archives. Unfortunately, simply using, boilerplate, a shared object is a bad thing: you need to know what you’re doing.
For instance, if your software simply uses a single executable, propose no API for other software to use and you don’t use plugins then you really should not be using libraries at all, and should rather link everything together in the executable. This avoids both the execution overhead of PIC code, and the memory overhead of relocated data .
And again, here are some explanation:
- if you’re installing a plugin you usually just need the shared object, but if the software using it supports external built-ins (I can’t think of even a single example of that but it’s technically possible), then you might want to consider making the static archive version optional;
- you only install header files if your package provides a public API (it’s a library) or if it uses plugins (plugins need an interface to talk with the main program’s body);
- if you’re going to share code between different executables, like inkscape does for instance (it does it wrong, by the way), what you want is to install a shared object (there is an alternative technique, but that’s a different matter and I’ll discuss that in the near future hopefully);
- if you’re installing a single executable, you probably want to install no library at all; this might not be the case if you use plugins though, so you might have to think about it; while application can easily make use of plugins (zsh does that for instance, this takes away at least some error checking at linking time; this is, anyway, simply a matter of development practice, you can still use plugins with no library at all);
- if you’re installing a library (that is, anything with a public API in form of header files), then you’re obviously going to install a shared object copy of it; the static archive version might be actively discouraged (for plugin-based libraries such as PAM, xine, Gtk+, …), or might simply be made optional for the remaining libraries.
Since I have been still fighting with the damned .la files and I’m pretty sure that even though I have explained some use cases most of my colleagues haven’t really applied them, I decided to go with a different approach this time: graphical guides.
Since the post about the tree size has gotten so much feedback, probably because the graphs impacted on people, this might actually prove useful.
Note: I first tried to draw the chart with Inkscape, but the connector available on its code only draws straight lines, which are unusable for stuff like this; I found no way to anchor lines to an arbitrary point of objects either, so I gave up; dia is tremendously bad to work with; kivio 2 is not in Portage nor available as binary package for either Windows or OSX; OpenOffice to the rescue, worked almost flawlessly, unfortunately I didn’t want to waste time to define customised colours so you get the bad and boring ones in the image.
As you can see from this graph, my idea is that, at the end, every .la file is removed. Of course this is not immediate and depends on a series of factors; this graph shows at least the basic question you got to ask yourself when you have to deal with shared libraries. Please note that this does not apply the same to plugins and for that I’ll post another, different flow chart.
- Does the package install internal libraries only? A lot of packages provide convenience libraries to share code between different executable programs (see this post for more information about it); this can be detected easily: there are no include files installed by default, the library is not in the ld path (such as
/usr/lib/packagename). In this case, the
.la files are not useful at all, and can be removed straight away.
- Does the package only install shared objects? The
.la files are only meaningful for static libraries that have no dependency information; if a package is not installing static libraries (
.a files) it needs not the
- Do the libraries in the package need other libraries? If the libraries are standalone, and only depend on the C library (
libc.so), then there is no dependency information useful in the
.la file, and can be dropped.
pkg-config the official way to link to the libraries? When using
pkg-config, the dependency information is moved inside the
.pc file, so the copy in the
.la file is redundant, and thus unnecessary.
- Is the package new? When adding a new package into Portage, there is no reason to keep the
.la files around when the conditions shown above apply. For packages that are already in portage, the removal of
.la files need to be considerate, or you’ll get the same kind of fire I got for trying to remove some (useless)
.la files out of the blue. Not a situation that I like, but so is life.