Moving musl's glibc compatibility symbols to gcompat
by A. Wilcox
Hi all,
Rich over at musl has expressed interest in moving their glibc
compatibility symbols into gcompat. Then libgcompat would become an
implicit DT_NEEDED on any software that has a DT_NEEDED of libc.so.6.
See below forwarded message from the musl list for more information.
Best,
--arw
-------- Forwarded Message --------
Date: Wed, 17 Jul 2019 14:16:51 -0400
From: Rich Felker <dalias(a)libc.org>
Subject: Re: [musl] 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
1 year, 9 months