[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 24 Dec 2015 00:16:25 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: musl & proprietary programs
On Thu, Dec 24, 2015 at 12:04:42PM +0700, Рысь wrote:
> On Wed, 23 Dec 2015 18:00:12 -0200
> Alba Pompeo <albapompeo@...il.com> wrote:
>
> > I also don't want to pollute my system with glibc. That's why I asked
> > if there was any plan to improve musl support of proprietary programs
> > like the ones I listed.
> > But as a last resort, I think Rich's method is the best so far, but
> > I'm a bit lost on the details since I'm not a libc expert.
> > I couldn't find a wiki page detailing Rich's method on Void or Alpine
> > (the 2 distros I know use musl). Is there a step-by-step for a novice
> > somewhere?
>
> 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).
That's the situation for x86 and mainstream archs, at least. Some
other archs have additional differences due to further brokenness in
glibc (like IBM double-double on powerpc).
Rich
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.
