Subject: Static linking of Citrus modules
To: None <firstname.lastname@example.org>
From: Joerg Sonnenberger <email@example.com>
Date: 07/14/2005 17:17:51
the current lack of static linkage support for
Citrus has been discussed in the past.
There are three options:
(a) Keep the status quo, effectively only supporting POSIX locale.
(b) Link all modules into libc. This is what lib/18151 provides. It adds
approximately 50k on IA32 for all modules (number from DragonFly, but
should be similiar to NetBSD). It doesn't allow addition of new modules
without recompiling libc.
(c) Use linker sets or similiar mechanism to selectively link modules
in. This is what I implemented in DragonFly
The advantage is no additional bloat for programs not needing it and
a degree of high customisation for those which do. Downside it that
the automatism only works for ELF and the linker needs a trigger to read
the archive (via explicitly referencing symbols for example, see the
thread). For non-ELF platforms, it might be possible to simulate this by
making the table itself a weak symbol, so that libc links fine. For
linking of Citrus modules, the table is created as part of the program.
My question is, which solution is prefered for NetBSD? I can port the
changes for (c) and provide the missing pieces, others have provided the
patches for (b).