Re: Removing glibc from the musl .2 ABI

[Rich Felker <dalias@libc.org>]

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