Moving musl's glibc compatibility symbols to gcompat

Wednesday, 17 July 2019

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&gt;
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

2021

2020

2019

2018