[patch] build shared libraries

[Bernhard Fischer]

Rob, vodz, Allan,

On Mon Sep 5 12:07:12 PDT 2005, Rob Landley wrote:
>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. :)

I can have a look at it. Allan, if you like, please send me that patch
so we can work on that together.
>
>My make-fu sucketh.
>

>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...

Well, if some other applet uses libbb.so, there ought to be the
possibility to make busybox peruse libbb.so too instead of linking libbb
in statically. It's an option which should default to the old behaviour
of linking libbb statically but also allow for the dynamic case, imo.
>
>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...

Ok. I'll do that.
>
>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...

There's also a  llist_add_to_end() in ifupdown.c which should be moved
to llist_add_to.c ...

IIRC i put a patch in the bugtracker which did that and provided
llist_free_one() and llist_free_all() functions.

vodz, are you willing to take care of those llist proposals?

>
>> # 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...)

Perhaps fakeroot(1) would help there?
>
>Working on the easy ones first. :)
>
>Rob