libbusybox is back; "individual" mode is introduced

[Denys Vlasenko]

On Thursday 11 October 2007 15:23, Bernhard Fischer wrote:
> >I looked into making libbusybox.so executanle itself, but
> >it looks like that needs a lot of linker magic for questionable
> >gain - I can have tiny (less than 3k) "busybox" executable
> >linked against it providing the same functionality.
> >
> >Any specific reasons why do you like to have
> >PIE busybox-which-is-also-libbusybox?
> 
> I don't have a real use-case right now (I used to do this a while back
> for XXX_main and some helpers from libbb, fwiw)
> but it could be used to either
> -) use XXX_main in other progs
> -) use stuff from {*/,}lib*/*c in other progs
> -) replace zlib, provided that a compatible interface is exported (not
> yet implemented, IIRC)

As of today, *all* busybox code goes to libbusybox
if CONFIG_BUILD_LIBBUSYBOX=y, busybox binary is only
a really trivial thunk:

   text    data     bss     dec     hex filename
    988     260       4    1252     4e4 busybox
 745254   12570   12032  769856   bbf40 libbusybox.so.1.8.0.svn

This basically gives you what you want in terms
of minimizing size of the on-disk files.

PIE approach will combine these two files. Maybe it is
aesthetically nicer, but no real win in size.

> The zlib case would be a very, very nice thing to have, IMO

You mean - ability to use zlip (de)compressor from busybox?

> (in case you 
> already drained your TODO list too much :)

My TODO list is
- have NOMMU test config running in qemu (need help with this)
- attack "invisible" sources of mem consumption,
  like stack usage
- phase out lash in favor of hush
- improve hush

--
vda