Compat symbols in abilist files

  I've come up with the attached patch to mark compat symbols as such in 
the abilist files.

Do we want to do this?  The downside is that when building glibc in 
certain non-standard configurations, some symbols are not compat symbols 
anymore (the prime example is probably --enable-obsolete-rpc).  On the 
other hand, the additional verification is valuable.

Thanks,
Florian
  

On Apr 13 2017, Florian Weimer <fweimer@redhat.com> wrote:

> Do we want to do this?  The downside is that when building glibc in
> certain non-standard configurations, some symbols are not compat symbols
> anymore (the prime example is probably --enable-obsolete-rpc).

Does that mean check-abi fails in that case?

Andreas.
  

On 04/13/2017 03:16 PM, Andreas Schwab wrote:
> On Apr 13 2017, Florian Weimer <fweimer@redhat.com> wrote:
> 
>> Do we want to do this?  The downside is that when building glibc in
>> certain non-standard configurations, some symbols are not compat symbols
>> anymore (the prime example is probably --enable-obsolete-rpc).
> 
> Does that mean check-abi fails in that case?

Yes, it would.

Thanks,
Florian
  

On Thu, 13 Apr 2017, Florian Weimer wrote:

> I've come up with the attached patch to mark compat symbols as such in the
> abilist files.
> 
> Do we want to do this?  The downside is that when building glibc in certain
> non-standard configurations, some symbols are not compat symbols anymore (the
> prime example is probably --enable-obsolete-rpc).  On the other hand, the
> additional verification is valuable.

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.
  

On 04/13/2017 09:09 AM, Florian Weimer wrote:
> I've come up with the attached patch to mark compat symbols as such in the abilist files.
> 
> Do we want to do this?  The downside is that when building glibc in certain non-standard configurations, some symbols are not compat symbols anymore (the prime example is probably --enable-obsolete-rpc).  On the other hand, the additional verification is valuable.

I think this is a good idea. We should detect changes in compat symbols as ABI breakage.

The upstream glibc abilist files should be for the default supported configuration.

Downstream distros should patch the abilist to match their configuration changes.
  

On 04/18/2017 06:18 PM, Joseph Myers wrote:
> On Thu, 13 Apr 2017, Florian Weimer wrote:
> 
>> I've come up with the attached patch to mark compat symbols as such in the
>> abilist files.
>>
>> Do we want to do this?  The downside is that when building glibc in certain
>> non-standard configurations, some symbols are not compat symbols anymore (the
>> prime example is probably --enable-obsolete-rpc).  On the other hand, the
>> additional verification is valuable.
> 
> 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?
  

On 04/19/2017 04:06 AM, Carlos O'Donell wrote:
> Downstream distros should patch the abilist to match their configuration changes.

I'm not sure if I agree with that.  I'd prefer if these files remained 
unmodified because differences threaten portability across distributions.

Is anyone except Fedora compiling current glibc versions with the 
--enable-obsolete-* flags?  Then we'll need a more intelligent ABI 
differ.  (If it's just Fedora, I'd prefer moving Fedora forward.)

Thanks,
Florian
  

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