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.
-------- 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.