Re: How can I assess compatibility of a statically linked binary?

[Rich Felker <dalias@aerifal.cx>]

On Thu, Feb 20, 2014 at 06:20:51PM +0000, Oliver Schneider wrote:
> > Musl is built on the Linux syscall layer. Linux kernel >=2.6.39 is
> > necessary for POSIX conformant behaviour, older kernels will work
> > with varying degrees of non-conformance, 2.4 kernels will only work
> > for simple single-threaded applications.
> 
> 
> I had mistakenly expected it under
> 
>   <http://wiki.musl-libc.org/wiki/Compatibility>
> 
> when it was of course to be found under:
> 
>   <http://wiki.musl-libc.org/wiki/Supported_Platforms>

This will also be documented more formally in the official manual to
be released in conjunction with musl 1.0. For this we should clarify
what version is really needed. I don't think 2.6.39 is necessary;
something like 2.6.32 should be sufficient for POSIX 2008, barring any
arch-specific bugs (or just general bugs that need to be patched to
avoid having an unstable/insecure kernel). I know glibc is planning on
requiring at least 2.6.32 in the next release, so it would be nice if
we could just state the same requirement.

As for older kernels, somewhere down to 2.6.22 works if you don't care
about atomic close-on-exec working atomically (musl has fallback for
kernels that lack it, but the fallback is of course non-atomic). Then
there are also ranges going all the way back to 2.6.0 or even 2.5.x
that work if you don't care about certain POSIX signal semantics
(mainly, wrongly-generated EINTR where a syscall should have
restarted) and don't need *at() functions (note that musl presently
does not emulate these, even though it could do so using /proc). And
if in addition you don't need threads, even 2.4.x will work. It would
also be nice to get these version ranges documented in detail, in case
anyone has need to use musl binaries with such old kernels (some users
adding new software to existing embedded systems may care; otherwise
it's probably a non-issue).

Rich