From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84224 invoked by alias); 19 Apr 2017 09:46:35 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 84207 invoked by uid 89); 19 Apr 2017 09:46:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy= X-HELO: relay1.mentorg.com Date: Wed, 19 Apr 2017 09:46:00 -0000 From: Joseph Myers To: Carlos O'Donell CC: Florian Weimer , GNU C Library Subject: Re: Compat symbols in abilist files In-Reply-To: Message-ID: References: <6453f4f9-75b5-68b9-0e6b-22f40aaee599@redhat.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-SW-Source: 2017-04/txt/msg00357.txt.bz2 On Wed, 19 Apr 2017, Carlos O'Donell wrote: > > I'd consider whether a symbol is a compat symbol to be part of the API, > > not the ABI; I don't think it belongs in these files. > > > > It may well make sense to be able to assert that a particular symbol is > > not available for new programs to link against, for either static or > > dynamic linking. Or that any given symbol has at most one non-compat > > version, in at most one library, except for cases (if any) explicitly > > whitelisted as deliberately having public versions in more than one > > library. > > Could you expand on why you think this is not part of the ABI? The ABI is about what (already linked) binaries (executables and shared libraries) work with a given glibc installation. Whether or not a symbol is a compat symbol does not affect which executables and shared libraries work with it. It affects what source code can be built and linked with that glibc, which is an API issue, not an ABI one. (The interface to .o files is not expected to be stable, if e.g. one glibc version uses an implementation-namespace function in an inline function in a header, but a subsequent version removes that inline function and changes that symbol to a compat symbol.) -- Joseph S. Myers joseph@codesourcery.com