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