BusyBox dynamic linked on uClibc for init? [resources usage] (fwd)

Tomasz Czapiewski xeros at irc.pl
Thu May 12 13:03:45 UTC 2011

>> Can BusyBox be compiled with dynamic link on uClibc as init?
>> For now I use static binary.
>> For space reasons I'm thinking about dynamic link.
> As Bernhard said, no problem at all.
> (I apologize if you already know the following - I'm writing it just
> in case.)
> However, I would really recommand to *think twice* and study your
> system *carefully* before changing to dynamic linking "for space reasons".
> * Busybox already saves you a lot of space, both in storage and in RAM,
> by packing several utilities into the same binary. Every busybox applet
> running on your system is already sharing *a lot* of memory with all the
> other ones.
> * The uClibc is well-suited to static linking, i.e. it does not pull
> unnecessary bloat into your binaries when you link them statically.
> If your system is similar to most embedded systems out there, then you
> only have a small number of processes running at any time. Most likely
> you have busybox for small standard services, and a big ugly binary for
> for your dedicated application. In that case, dynamic linking will not
> do much for you, either for RAM gain or storage space gains.
> Shared libraries and dynamic linking are most useful in the following
> case:
> - You are simultaneously running a lot of distinct binaries on your
> system;
> - Said distinct binaries have a lot of code in common, for instance
> because they share part of their functionalities (think X clients);
> - You can't afford to recompile your whole system when you upgrade
> one library.
> Full-fledged GNU/Linux desktop systems are the typical case where
> dynamic linking is beneficial (this is one of the reasons why dynamic
> linking is so prevalent). Embedded systems, on the other hand, are the
> typical case where it is not.
> So, before switching to dynamic linking, make sure you know exactly
> what you are doing, and why.

Thank you all for confirmations.

And thank you very much for explanation.
I haven't known all of those, I'm just starting work in embedded world.

The device has MIPS based CPU in mipsel arch and it's running Linux.
I use one BusyBox static, stripped binary with most applets compiled in, and 
it's size is around 1,4MB.
Dynamic linking (without PIC) gives me 1MB binary.
Most of the time there are only few BusyBox processes running but in some cases 
(many shell and cgi scripts) there can be a lot more BusyBox processes running 
at once and some other than BusyBox processes can take most CPU and memory 
usage at times.
BusyBox is used quite extensively on this machine.

So, dynamic linking could make more CPU and memory usage or simmilar in this 
Should I compile BusyBox with Position Independent Code for smaller memory 
usage or not?
I have at least few megabytes of RAM for all BusyBox processes.
Most of the time there are these applets used: echo, ps, cp, mv, mkdir, rm, 
cat, grep, tee, pwd, ls, sed, awk, test, head, tail, httpd, mount, insmod, 
lsmod, rmmod, kill, killall, ln,...
and rarely: dd, mke2fs, flash_eraseall, tar, gzip, gunzip, ifconfig, cryptpw, 
passwd, top, vi,...).

I have read FAQ section: "Memory used by relocatable code, PIC, and static 
linking" but I still don't know the clear answer.

Tomasz Czapiewski

More information about the busybox mailing list