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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
