[BusyBox] Building individual applets standalone.

[Rob Landley]

On Tuesday 31 May 2005 07:39 pm, Bernhard Fischer wrote:
> On Thu, Mar 17, 2005 at 02:17:21AM -0500, Rob Landley wrote:
> >I got bored, so here's a script and a .c file that builds a dozen or so
> >busybox applets standalone.  Proof of concept, as it were...
>
> I also sometimes wanted to have standalone applets, fwiw.

Building the applets is pretty straightforward: the post you quoted from has 
the magic for a few, and the rest should follow logically.

The problem is I have very little make-fu.  (I hate make.)

> Let's start building a libbb.so. If this is ok, then i'll cover the
> other libs too.
>
> - If CONFIG_STATIC is not selected, build the helper-libs as shared
>   objects and dynamically link to them.
> - If CONFIG_BUILD_LIBRARIES is selected then build all libraries static
>   as well as dynamic. This makes reusing the libraries of busybox
>   easier.

Hmmm...  Sounds like CONFIG_STATIC should be a tri-state.  Statically link, 
normal dynamic link, or standalone applets with libbb.so.

Do we care about being flexible enought to have statically linked standalone 
applets?  (If they're wasting that much space anyway, they can just make 
allnoconfig, switch on the applet in question, and viola.  The overhead of 
<4k of busybox_main isn't going to kill them if they're statically linking 
everything anyway.  But I could be wrong about this...)

> Does someone know how to allow for tristate to work? I'd be glad to hear
> about it as it's not obvious to me how to "enable" it, from a short
> glance.

Look at the linux-kernel menuconfig.  That's what we copied.  I think we've 
upgraded to the 2.6 stuff by now...

> >If anybody wants to teach the actual makefiles how to do this, I'm
> > interested in collaborating.
>
> get_terminal_width_height.c is specified more than once in the Makefile.
> Please apply the second snippet of the attached patch
> (busybox/libbb/Makefile.in).

Hmmm...  I don't think we need a config option to _build_ the shared library.  
That's just an extra linker invocation; it's pretty fast.  The config option 
is for whether or not to _install_ the new .so, and whether or not to link 
busybox against it.  And really, does it buy us anything to build libbb.so to 
link an otherwise monolithic busybox against it?  (Shared by one app?)

Now if that libbb.so is exporting zlib interface, and/or a stripped down fake 
termcap or some such...

> I can split that fix off the rest if needed.

Yes please.

Rob