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.