Static linking considered harmful

[Jakub Jelinek]

On Thu, Nov 23, 2006 at 08:02:33AM +0100, Florian La Roche wrote:
> > Again, nobody is taking away the possibility to create partially 
> > statically linked apps.  I'm all for that as long as no maintenance 
> > borders are crossed.  This is what -Wl,-B,static and -Wl,-B-dynamic are for.
> 
> Then we should not remove too many static libs. Some are good candidates
> to only keep the real core (LSB?) libs dynamically loaded.

A library that is usable with -Wl,-Bstatic -lfoo -Wl,-Bdynamic needs
a) justification
b) quite a lot of work on the Makefiles etc. side, particularly:
   - it should be built as -fPIC, because you never know into what it
     will be linked
   - make sure all global symbols are hidden (i.e. play a lot with
     visibility attribute and/or #pragma GCC visibility, what's worse
     is that you want the symbols exported for *.so but hidden
     in *.a) - without this, when you link it statically into some
     shared library, it reexports all the symbols to other libraries
   - make sure the library doesn't rely on something being unique
     per-process (e.g. libgcc's unwinder, at least when older libraries
     are used, must have a unique registry of loaded objects, libstdc++'s
     mt_allocator relies on ODR, otherwise you need to track where you
     allocated things and never deallocate them from a different object,
     etc.)
So, while I think there are a few cases where keeping an *.a archive
around is desirable and worth the above pain, for the vast majority
of libraries the justification isn't strong enough and *.a should be
just nuked.

	Jakub