[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 17 Jul 2019 14:16:51 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Removing glibc from the musl .2 ABI
On Wed, Jul 17, 2019 at 01:10:19PM -0500, A. Wilcox wrote:
> >> Just trying to make sure the community has a clear view of what this
> >> looks like before we jump in.
> >
> > Yes. This isn't a request to jump in, just looking at feasability and
> > whether there'd be interest from your side. Being that ABI-compat
> > doesn't actually work very well without gcompat right now, though, I
> > think it might make sense. I'll continue to look at whether there are
> > other options, possibly just transitional, that might be good too.
>
> I meant: I want a clear view of the boundaries between musl and gcompat,
> before we (Adélie / the gcompat team) jump in and start designing how we
> want to handle all the new symbols we may end up with :)
If we go this route, I would think that gcompat could provide all
symbols which are not either public APIs (extensions you can
legitimately use in source) or musl-header-induced ABIs (for example
things like __ctype_get_mb_cur_max, which is used to define the
MB_CUR_MAX macro). This would include LFS64 as well as the "__xstat"
stuff, the other __ctype_* stuff, etc.
> We also were considering setting up a dedicated gcompat site so that the
> community could share apps that are known to work / fail, symbol
> presence, LSB missing symbols, etc. Would that be of interest from your
> side as well?
Definitely, regardless of whether we go ahead with the above or not.
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.
