From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14411 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Removing glibc from the musl .2 ABI Date: Wed, 17 Jul 2019 14:16:51 -0400 Message-ID: <20190717181651.GN1506@brightrain.aerifal.cx> References: <20190717033735.GJ1506@brightrain.aerifal.cx> <2d36174f-ae85-bcd2-1c71-10f50513b1a6@adelielinux.org> <20190717151107.GL1506@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="253786"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14427-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jul 17 20:17:07 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hnoUF-0013xB-0N for gllmg-musl@m.gmane.org; Wed, 17 Jul 2019 20:17:07 +0200 Original-Received: (qmail 23996 invoked by uid 550); 17 Jul 2019 18:17:05 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 23965 invoked from network); 17 Jul 2019 18:17:04 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14411 Archived-At: 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