Hello. 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 busybox. 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. Thoughts? Thanks, /mjt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5432b4db.8060...@msgid.tls.msk.ru
