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 _______________________________________________ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox