|
Message-ID: <20151224104009.GT23362@port70.net> Date: Thu, 24 Dec 2015 11:40:10 +0100 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: musl & proprietary programs * Rich Felker <dalias@...c.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 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.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.