Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.