Re: Creating a statically linked executable for a LuaJIT+C program

  • From: Coda Highland <chighland@xxxxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Tue, 30 Oct 2012 07:52:32 -0700

On Mon, Oct 29, 2012 at 5:01 PM, John Spencer
<maillist-luajit@xxxxxxxxxxx> wrote:
> slimmest and/or most conformant one...

I said "suitable", dude.

>> Disk space isn't the determining factor here and I was making no
>> claims about it.
>
> i don't know where disk space came into the play, but a small (as in disk
> usage) static binary does indeed use very little ram for the libc functions
> it uses.
>
> i remembered that rich (musl's author) recently said something about this
> topic, so i asked on the musl ml, here's his reply:
>
> http://openwall.com/lists/musl/2012/10/29/4
>
> since this gotten pretty OT for this list, maybe we can continue the
> discussion there.

I'm not gonna go subscribe to another ML just for one discussion, so
I'm going to just reply here. If you really want to move it off-list,
you can just add my address to the message, but this argument isn't so
important to me that I even care about going out of my way to win it.

Rich very clearly put a condition on it: IF you use less than the
dynamic linking overhead, THEN you save RAM. Plus, he's trying to
reduce the dynamic linking overhead, which makes the requirements for
saving RAM even stricter, and also as he said there are ways to make
dynamic libraries even more efficient. And when talking about the
system libc, it's probably ALREADY in RAM thanks to system daemons and
the shell using a pretty diverse selection of functions.

So yes, there's always an exception. Very tiny apps are one of them;
it may make sense to link a suite of very small single-purpose applets
to a static libc. (Although BusyBox seems to indicate that in this
case another option is to unify them all into a single larger app and
then switch on argv[0]. This gets to share RAM for the entire binary.)

Long story short, and repeating the point I was expounding upon
repeatedly before: There is no one best solution, and it's not evil to
dynamically link a portable binary to libc. Consider your target and
your needs, and choose what's best for you.

/s/ Adam

Other related posts: