[patch] build shared libraries

[Rob Landley]

On Tuesday 06 September 2005 04:28, Bernhard Fischer wrote:

> >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'm all for it, but "one busybox executable you can drop on a system, but 
which expects libc.so.2 to be there" is different from "one busybox 
executable that also needs a shared library installed in order to work", and 
that's different from "one busybox executable, indivisible, with static 
linking for all".

Three options.

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

Cleaning up libbb/ and friends is probably the kind of task that hercules 
would have diverted a river through.  If vodz is really trying to make our 
makefile dependencies work sanely without "make clean" thrown in after a 
config, somebody's probably going to have to tackle the "grep L_ libbb/*.c" 
mess which I don't personally understand yet...

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

Possibly, but I'd rather not introduce external dependencies if I can avoid 
it.  (Especially if they're _only_ needed to test, thus guaranteeing that 
nobody will ever test because nobody installs dependencies just for the test 
harness.  Heck, I could use user mode linux for this just as easily...)

It should be possible to do a static build, drop it into a directory, and 
chroot into there.  That requires root access to test, but is unlikely to 
damage the system no matter how wonky the tests go...

We can also give them multiple options.  Fakeroot, UML, chroot...

Rob