If it was built with dynamically linked glibc, though, would it really matter? busybox has no external dependencies other than, if dynlinked, a couple of standard support libraries (libc, libm, libresolv, libcrypt), so it should still work everywhere that has a more recent version of glibc than its build environment (and people who build redistributable binaries usually use the oldest glibc they can lay hands on, for exactly this reason).
And that is a bigger and bigger requirement, because glibc is less and less ubiquitous. Having a busybox binary that's independent from glibc is interesting per se because its uses are not limited to environments that do provide glibc. And there are more and more distributions, even doing non-embedded, that do not use glibc - and there are even cases where it makes sense to run them in WSL. And there are also cases where it makes sense not to want to rely on the official prebuilt busybox binary. I'm not commenting on the rest of the discussion, because I have zero horses in the race, but I wanted to underline this point. Do not make judgments on other people's use cases. -- Laurent _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
