[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