From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14398 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: Thu, 11 Jul 2019 21:45:27 -0400 Message-ID: <20190712014527.GB1506@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="213676"; 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-14414-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jul 12 03:45:43 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 1hlkd5-000tTv-2g for gllmg-musl@m.gmane.org; Fri, 12 Jul 2019 03:45:43 +0200 Original-Received: (qmail 24434 invoked by uid 550); 12 Jul 2019 01:45:40 -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 24416 invoked from network); 12 Jul 2019 01:45:40 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14398 Archived-At: On Thu, Jul 11, 2019 at 06:58:38PM -0500, A. Wilcox wrote: > (Full disclosure: I am the principal author of gcompat.) > > Hi, > > Now that gcompat has matured, I was wondering if perhaps musl should > consider dropping the glibc ABI guarantees when the "2 ABI" lands. It's not decided that it will, or at least not in the near term. I think the other approach proposed to 64-bit time_t is a lot more appealing to most existing 32-bit users. I've had out-of-band feedback from one big user that they depend on ABI stability for the existing 32-bit arch+ABIs and hope there won't be a hard Y2038 EOL for them, and I myself would also rather prefer not to have to do an ABI switch. >From the beginning, ABI stability was one of the big promises of musl. I realize we have "enough" time between now and 2038 for putting off an ABI switch (except for ppl making embedded stuff with really long lifetimes), so that users who care about ABI stability could stick with .1 "for now", but then we just push the problem back and they're unhappy in some moderately-distant future, and probably end up in a mess when they realize they need time_t's representing times a decade or two out sooner than they thought... > This would make the LFS64 symbol mess completely moot. Yes. Actually I'd like to move all of the ABI-compat symbols out of ld-reachable symbol table and make them ABI-compat only. But I'd also like to *improve* ABI-compat, e.g. making regexec from glibc libs safe on 64-bit (where their regoff_t was wrong), > It would also allow musl to "fix" a lot of dumb glibc decisions. I'm > thinking specifically here of things like ctermid(3), which musl could > actually implement correctly if it wasn't being held back by glibc > defining L_ctermid as 9. ctermid is something of a junk function anyway, but there are similar non-junk interfaces affected. Identifying and overhauling them all is probably a bigger project than I want to take on now, but I still think it's a promising direction at some point in the future. Ideally this might go hand in hand with making musl less Linux-centric, in the form of developing a types ABI that's uniform across archs and meant to be used natively on bare metal or non-Linux kernels. > I'm aware this is probably controversial, and it will probably be shot > down quickly, but I thought I would at least suggest this as an option. > > Thank you for your consideration. Thanks for the feedback. Rich