[arch-dev-public] klibc static or shared building
On 10/31/07, Thomas Bächler <thomas@archlinux.org> wrote:
Changes in these versions:
klibc: - compile shared binaries by default (somehow this defaults to static in klibc 1.5) - patch klibc to be able to build klibc-module-init-tools - don't build insmod - rebuild against 2.6.23 headers
klibc-extras: - update to 2.3, removed modprobe
klibc-udev: - rebuild for new klibc, enable shared linking again
klibc-module-init-tools: - initial commit to the repository (replaces insmod from klibc and modprobe from klibc-extras)
mkinitcpio: - Fix #8448 - Change the base hook to work with klibc-m-i-t
Just curious- what is the downside of building statically? It seems like it could be a plus in some ways, because you eliminate one more chance of breakage in early userspace. Of course, this also increases the size of your built binaries and increases the size of your initrd. -Dan
-----Oorspronkelijk bericht----- Van: arch-dev-public-bounces@archlinux.org [mailto:arch-dev-public- bounces@archlinux.org] Namens Dan McGee Verzonden: woensdag 31 oktober 2007 15:21 Aan: Public mailing list for ArchLinux development Onderwerp: [arch-dev-public] klibc static or shared building
Just curious- what is the downside of building statically? It seems like it could be a plus in some ways, because you eliminate one more chance of breakage in early userspace. Of course, this also increases the size of your built binaries and increases the size of your initrd.
The downside is that your binaries become a lot bigger. You don't want to include a full copy of klibc libraries in each binary in your initcpio image. Then, for the breakage: what could break? The early userspace tools are usually updated at the same time.
Dan McGee schrieb:
Just curious- what is the downside of building statically? It seems like it could be a plus in some ways, because you eliminate one more chance of breakage in early userspace. Of course, this also increases the size of your built binaries and increases the size of your initrd.
The binaries provided inside the klibc package were always compiled with -shared explicitly. The klibc-extras and klibc-udev were always compiled without -shared or -static, thus statically linked. This was an inconsistency, mixing static and shared binaries in the image. The "bug" I actually fixed was that klcc (without -static or -shared specified) linked a static binary, while gcc linked a shared binary, which is inconsistent. We can discuss building all klibc binaries statically, but then we do it by specifying -static in LDFLAGS explicitly, not by some weird klcc misbehaviour. About the breakage: When klibc is rebuilt, all klibc tools are rebuilt at the same time, so nothing should ever break.
participants (3)
-
Dan McGee
-
Jan de Groot
-
Thomas Bächler