[patch] build shared libraries
Rob Landley
rob at landley.net
Mon Sep 5 19:07:12 UTC 2005
On Monday 05 September 2005 04:54, Bernhard Fischer wrote:
> Hi,
>
> Attached patch adds CONFIG_BUILD_LIBRARIES.
>
> If set, lib*.a will be also build as shared libraries:
> ./libbb/libbb.so
> ./libpwdgrp/libpwdgrp.so
> ./archival/libunarchive/libunarchive.so
> ./networking/libiproute/libiproute.so
> ./coreutils/libcoreutils/libcoreutils.so
I got the start of a make standalone patch from Allan clark, turning my sick
little scripts into makefile stuff. (Haven't had a chance to look too deeply
at it yet; hopefully later today.)
If you and he could coordinate on this, that would be seriously cool. :)
My make-fu sucketh.
> If CONFIG_STATIC is set (which is the default), the busybox binary will
> use the static libs as before.
>
> If CONFIG_STATIC is not set, busybox will link against the shared
> variants of the libraries (1).
Um, a statically linked busybox vs a self contained busybox binary vs a
busybox binary that needs to install a shared library your system won't
already have...
This is three different options. The shared library makes sense for
standalone applets; not sure how much of an advantage it has for one big
busybox binary...
> # ldd bin/busybox
> libunarchive.so => /lib/libunarchive.so (0x40018000)
> libiproute.so => /lib/libiproute.so (0x400e2000)
> libpwdgrp.so => /lib/libpwdgrp.so (0x400f0000)
> libcoreutils.so => /lib/libcoreutils.so (0x400f3000)
> libbb.so => /lib/libbb.so (0x400f5000)
> libdl.so.2 => /lib/tls/libdl.so.2 (0x40105000)
> libm.so.6 => /lib/tls/libm.so.6 (0x40108000)
> libcrypt.so.1 => /lib/tls/libcrypt.so.1 (0x4012b000)
> libc.so.6 => /lib/tls/libc.so.6 (0x40158000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
I'd much rather there be one libbb.so. Maybe if libarchive started exporting
interfaces to replace libz and libbz2 and such, that might be a reason for it
to be separate...
Code shared between applets (and thus libbb) makes a lot of sense to me, but
code locally shared between applets (libcoreutils, libpwdgrp, etc) doesn't
seem to be a huge distinction.
The definition of "shared" is a bit stretched at times, actually.
libbb/read_package_field.c only seems to be used by dpkg.c, and
libbb/restricted_shell.c by su.c...
Speaking of which, I need to move xgetoptfile_sort_uniq.c into uniq.c, since
that's the only thing still using it...
> # ls -l bin/busybox
> -rwxr-xr-x 1 0 0 739044 Sep 5 09:38 bin/busybox
>
> Annotations:
> a) There are two files in libbb which use libcrypt: correct_password.c
> and pw_encrypt.c. Because of this libbb.so itself has to link against
> libcrypt. Is this intended, given that there is libpwdgrp?
I'm trying to get a better test suite so we can try cleaning up stuff like
that and seeing what breaks. Haven't quite figured out what to do about
stuff requiring root access to test, though. (Some kind of chroot
environment, perhaps? Standalone shell would need /proc mounted in the
chroot, but other than that it should work...)
Working on the easy ones first. :)
Rob
More information about the busybox
mailing list