Bug 282512 – System libraries lacking static build options

• Product: Gentoo Linux
• Status: RESOLVED CANTFIX

[Description Robert Bradbury 2009-08-23 22:03:00 UTC]

There are multiple "essential" system libraries which lack a static build option which should be provided to allow loading and retention of programs with specific library versions.

Reproducible: Always

Steps to Reproduce:
LIBRARIES (PACKAGES) which present with this problem (no static archive file):
1) libatk*.a (atk)
2) libdrm.a (libdrm)
3) libGL.a (mesa)
4) libgdk/gtk*.a (gtk+)
5) libhunspell*.a (hunspell)
6) libpango*.a (pango)

1. emerge PACKAGE_NAME


Actual Results:  
Missing archive library, typically /usr/lib/libPACKAGE_NAME.a


Expected Results:  
For standard system libraries, esp. those which have a "--enable-static" option in the library configure file, it should be possible to emerge *both* the shared libraries (.so files) as well as the static libraries (.a files).

I have produced static (.a) files for all of the libraries listed (typically using --enable-static when configuring).  The hunspell library is a special case, it does seem to produce a ".a" file but it is mis-named "/usr/lib/libhunspell-1.2." (this was only noticed in the process of filing this bug). 

It would be "nice" if the Gentoo ebuilds allowed configuration of one of (a) shared (default); (b) static (optional) or (c) shared + static but given the current use of the "static" USE flag this might be a bit difficult.  A robust Linux distribution, esp. a developer-friendly version such as Gentoo, should not preclude (or make excessively difficult) the building of static libraries where the end-user desires them (whether it be for downstream loading, e.g. Bug #282481) or simple "code reuse" of some small subset of an archive.  It should not be necessary for user to retain on disk or memory an entire shared library if only a small subset of a library is required.

The lack of the ability to retain static versions of programs, makes it difficult to resolve bugs (e.g. 2-3 year old Firefox gdk bugs) or build programs which can reasonably be expected to reproduce specific scientific results (in 5 or 10 or 15 years).

Yes, I *know* there may be problems with some of these libraries being used as static libraries (that is something that would be resolved by the user on a case by case basis).  If specific problems are known, it might be worth adding a note in the "Messages for package PACKAGE_NAME" in the ebuild output when "static" is used.

Leaving these static libraries out of the "standard" distribution makes no sense as most packages produce both the .a and the .so files (there are 1200+ .a files in /usr/lib).  The packages cited here are presumably oversights.

[Comment 1 Patrick Lauer 2009-08-26 08:23:45 UTC]

I think this is best discussed on the gentoo-dev mailinglist.

[Comment 2 Peter Alfredsen (RETIRED) 2009-09-06 20:52:27 UTC]

We had this discussion in the spring. IIRC, it was resolved that USE=static-libs should be used for static libraries, if a good case could be made for enabling them. I suggest you start filing bugs with patches for each of these packages. Usually, as you've said, it's as easy as padding IUSE with static-libs and adding $(use_enable static-libs static) to the econf line.  

[Comment 3 Peter Alfredsen (RETIRED) 2009-09-07 21:59:01 UTC]

Start on the bottom of the depgraph and work your way up with bugs+patches. Make sure you test them or people will get annoyed.

[Comment 4 Robert Bradbury 2009-09-08 01:35:27 UTC]

Peter, I would suggest that the list I proposed is such a list.  They are the libraries at the bottom of any robust X application, in my case firefox, that one wants to build as a static executable.  Most of them are near the bottom of a "depgraph" for system libraries, and I have built and tested them (as .a files) with older versions of the libraries to produce a quasi-static Firefox which worked properly.  This was done outside of the Gentoo build system due to the problematic layering of ebuilds on top of library configure files and the lack of a one-to-one mapping between USE flags and library configure options (as well as the fact that various library package developers seem be rather sloppy with respect to what --enable/disable-static/shared actually do.)

Now, lets assess the "problem" as it currently exists.  I've got ~1100 ".a" (static) libraries in /usr/lib.  I've got ~1500 shared libraries (.so) libraries in /usr/lib.  Most of these files, due to the fact that this is the default way many configure and intall scripts work, are the static/shared reflections of each other.  For a majority of them, probably 70-80%, I would guess that you could do away with the static libraries entirely because they are used in building a single set of executables (often times only one) or the executables only require the shared library.  Normally these packages could be configured with --disable-static in the configuration step of the build and it would make zero difference to the functioning of the installed system (except for freeing up space on /usr).

I've only got *20* packages, mostly sys-apps/*, which are compiled using the "static" flag (primarily I because I want a stable system where system utilities don't fail when I upgrade a library). I have no explicit uses of the static-libs flag because it is in effect (by default) for most packages at this point (even though it isn't generally needed).  There are only about a dozen packages, mostly XXX-libs, that make use of the "static-libs" flag in the ebuild files.

I could probably come up with the ebuilds to fix the problem for the cited libraries, but am not a gentoo developer and have no knowledge about the modifications would be integrated into the development/release system.  Fixing the subset I cite (which solves this bug) doesn't resolve the general problem that most of the static libraries produced by the various packages are never used and should presumably be removed (by making the default configuration for all packages be "--disable-static").  I would agree with Patrick that this is a topic for discussion/planning perhaps on the gentoo-dev mailing list.

But the primary focus of this bug is to get changes made to a handful of specific libraries to allow the static building of packages like Firefox, Galeon, etc.  Moving that forward would allow the long term stress testing of bugs (of which there are several in Firefox) that were/are primarily libgtk/libglib bugs (which were/are nasty bugs because they generally resulted in crashing Firefox).

[Comment 5 Thomas Capricelli 2010-03-10 18:15:11 UTC]

I'd too like to have a USE option to be able to install static libs. Unfortunately i'm not able to hack ebuilds by myself.

Though, my needs seem different, and i'm most importantly concerned with not-core libraries. Static linking is one solution today if you want to distribute a single binary that should work on different distribution... Thinks like libc or libm are available and mostly compatible accross distribution, but it would help to have static libs for other less mainstream libraries such as qt, gtk, qwt, png, libz.... (yes, libz.a is already available).