[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

static linking: alternatives for glibc?


For a very long time, we had a busybox variant which is linked statically,
for rescue or other similar purposes (for those who don't know, busybox
provides minimal implementations of varios system utilities so can be used
almost alone as a replacement for whole (minimal) system).

But with jessie, for one, all network name resolution (gethostby* etc APIs)
don't work anymore, because glibc does not provide them instatic libraries.
So usual network utilities in busybox does not anymore, they just return
`host not found' (unless you use IP addresses).

So I was thinking about alternatives for glibc in this context.  For busybox
it should be easy on one hand, because it does not depend/use anything else,
just libc and busybox itself; but difficult on another because busybox
uses a wide range of libc functions (especially low-level kernel interfaces).

So, I tried uclibc.  Just to discover that debian does not have binary
uclibc packages, only uclibc-source.  Tried to build uclibc from source
during busybox build, but this is a bit hackish, and does not exactly
work right: uclibc readme says it needs whole toolchain, including gcc
and binutils, to build applications against the library, which is quite
a bit overkill.  Trying naive approach, by contructing a minimal .specs
file for gcc, - but I don't know enough of gcc internals to write one,
I weren't able to make it to work.  And I don't know which probs this
approach will have on all "interesting" architectures debian supports.

Next alternative was dietlibc which has binaries.  But it turned out
that busybox does not build with it, too much stuff is missing from
dietlibc, and large patch is needed (for either dietlibc or busybox)
for things to start working.

Another alternative was musl, it provides libraries and it is almost
sufficient to build busybox.  But unfortunately it does not build on
all architectures where I'd like to build busybox-static.  Also, it
does not provide rpc which is used for nfs mount functionality in

So basically, I'm back to square one.  Maybe I can build busybox-static
against musl on those architectures where musl is present, and use
old glibc way on those where musl does not exist.  But that'd be
non-practical (but on the other hand, the most demanding and practical
platform for busybox-static is x86 anyway, where musl exists).

Another similar question is qemu -- qemu-user-static package.  It is
built statically to be able to use it in a foreign chroot without
worrying much about dependencies.  It too can benefit from some
more "static-friendly" libc (if not only to save space), but this
case is "a bit" more tricky: qemu ises glib heavily, and I'm not
sure libglib.a can be linked with anything but glibc.




Reply to: