Re: musl & proprietary programs

[Rich Felker <dalias@libc.org>]

On Thu, Dec 24, 2015 at 11:40:10AM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [2015-12-24 00:16:25 -0500]:
> > On Thu, Dec 24, 2015 at 12:04:42PM +0700, ???????? wrote:
> > > There is also problem that musl wishes not to be fully glibc compat.
> > > Certain libc structs and public structs coming from glibc headers that
> > > are not required to be ABI same will be different on musl for
> > > performance or optimization reasons, and programs relying on them
> > > usually will not be happy. Simple programs probably still will work.
> > 
> > There are no differences for performance or optimization reasons,
> > unless you want to count [u]int_fastNN_t which are basically never
> > used in public APIs anyway. Otherwise the only differences are that
> > musl lacks the 32-bit-off_t structures on 32-bit archs (i.e. it can't
> > match the _FILE_OFFSET_BITS=32 ABI on glibc, but it's not safe to use
> > this ABI anymore anyway) and that musl does not copy the
> > non-conforming, unsafe-because-it's-too-small glibc regoff_t on 64-bit
> > archs (this only affects regexec).
> 
> thread cancellation cleanup abi is different too
> (because glibc is broken for async-cancel)
> but nobody uses that so it should not be a problem

Indeed, I forgot about that because it's not a types difference. I'd
thought about possibly trying to support that too, but it looks hard
and not worth the effort (or other costs).

> the nvidia dso may segfault for many reasons, iirc
> the last time we identified that it uses stdio in
> a broken way, but there are numerous problems so
> a crash should not be a surprise.

Indeed, I think we found that it's assigning to stdout, which aside
from being utter nonsense (stdout is not even specified to be an
lvalue), happens to crash since musl's stdout is const and thus
usually in read-only/relro memory.

Rich