You might remember that in my graphical post I tried making it clear that in some cases static libraries are not only unnecessary, but also unusable. It so happens that not everybody has that clear yet, so let me try to explain a bit more where this USE flag is unwarranted entirely.
Language bindings. While it is technically possible to have static extensions built in in Ruby and Python, said situations are very convoluted and aren’t really solid enough to be used for Gentoo packaging; those who want to go with that route are generally using custom build systems, because they require to build in the whole interpreter and binding libraries together.
This means that, to give an idea, these archives shouldn’t have been there to begin with:
/usr/lib/python2.7/site-packages/beagle/beagle.a
/usr/lib/python2.7/site-packages/pygetdata.a
/usr/lib/python2.7/site-packages/numpy/core/lib/libnpymath.a
/usr/lib/python2.7/site-packages/_mathgl.a
/usr/lib/python3.2/site-packages/numpy/core/lib/libnpymath.a
Note: there are no Ruby files in that list, but just because the tinderbox is currently unable to build any Ruby version due to GLIBC 2.14 issues that are yet unresolved upstream.
So if you’re building language bindings, adding a static-libs USE flag is just pointless: remove it and disable static libraries altogether, so that you don’t have to build source files twice (PIC and non-PIC).
Runtime-loaded plugins. It is unfortunate how little developers know about the limitations of runtime-loaded plugins (i.e., all plugins; I’m just making it clear, because buildtime-included plugins are rather built-ins). One of these is the fact that you only need the .so file to load them. So these are certainly smelling funny:
/usr/lib/gstreamer-0.10/libgstmimic.a
/usr/lib/gstreamer-0.10/libgstvp8.a
/usr/lib/libvisual-0.4/morph/morph_alphablend.a
/usr/lib/libvisual-0.4/morph/morph_flash.a
/usr/lib/libvisual-0.4/morph/morph_tentacle.a
/usr/lib/libvisual-0.4/morph/morph_slide.a
/usr/lib/libvisual-0.4/actor/actor_lv_scope.a
/usr/lib/libvisual-0.4/actor/actor_jakdaw.a
/usr/lib/libvisual-0.4/actor/actor_oinksie.a
/usr/lib/libvisual-0.4/actor/actor_bumpscope.a
/usr/lib/libvisual-0.4/actor/actor_gforce.a
/usr/lib/libvisual-0.4/actor/actor_infinite.a
/usr/lib/libvisual-0.4/actor/actor_lv_analyzer.a
/usr/lib/libvisual-0.4/actor/actor_corona.a
/usr/lib/libvisual-0.4/actor/actor_JESS.a
It is true that libtool’s libltdl theoretically allows you to decide at build time whether to build the code in or use it as a plugin, but even then, only one version of the two is ever needed. So if your package only installs one of these, simply remove the USE flag and disable static libs altogether; pretty please.
Also note that while there are packages that allows you to use plugins or builtins, for instance Apache allows you to choose whether to build the modules in or build plugins to load at runtime. But this only works for first-party modules, as building third party modules within Apache requires to have their sources available when building Apache itself.
Libraries relying heavily on plugins. Similarly, if you’re packaging a library that includes a plugins’ system, it is almost certain that the plugins link back to the library. This is actually required to avoid underlinking and to ensure that no undefined symbols are present in the final link of the plugin (well, there are exceptions, but let’s not dig into those right now).
Why in this case you don’t want static libraries? Well, if you were to build a frontend against the static library, it would then load the plugin and the dynamic library as well, not only doubling the loaded code, but causing symbol collisions one with the other, which is fine only until the two versions get out of sync (i.e. you update the library package, without rebuilding the frontend).
This only works if you can convert all the plugins into builtins on the fly, but I know of no project that allows you to do that.
Almost everything else. Don’t get me wrong, I knwo that sometimes we do need static libraries. But it’s also true that in most cases we don’t. I don’t know why people insist on having static-libs an USE flag by default. My personal preference would be to have static-libs as an USE flag when it is actually being used.
This means that unless there are reverse dependencies building against the static libraries, the package should not have the static-libs USE flag at all. Unfortunately this requires the user to enable it forcefully when they want to build something statically (and I admit it happened to me before a time or two).. but let’s be real: most people will not do that.
Indeed, if it wasn’t for PostgreSQL and lvm2/udev (the latter of which I would have avoided with a USE=-static on lvm2), I don’t think I would have noticed the DWARF-4 binutils bug that I had lingering on my system for over a month!