Trying to understand the -fabi-version=n and -fabi-compat-version=n options

Trying to understand the -fabi-version=n and -fabi-compat-version=n options

[Dallman, John]

I'm employed by a company that produces libraries for mathematical modelling. I'm doing this on CentOS 7.x with its bundled GCC 4.8. One of the consumers of my libraries (and many other libraries) wants to start using GCC 7.3, and later, GCC 9.2. They're worried about C++ linkage compatibility, and we don't agree over the interpretation of the GCC manual's documentation of  the -fabi-version=n and -fabi-compat-version=n options. We aren't having a fight about this, but I need to sort it out.

So I'm hoping someone can check my reasoning. I'm having to reason, because I don't have ready access to a system with anything later than GCC 4.8 on it.

I'm looking at https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc.pdf, pp. 44-45. My consumer wants to use the options:

       -fabi-version=7 -fabi-compat-version=2

Which they think says "behave just like 4.8". However, I think that says something a bit different:

1. Compile code as if the compiler were GCC 4.8, doing the mangling with the /new/ ABI of GCC 4.8.

2. Provide aliases for symbols the compiler creates, as if it were GCC 3.2 to 4.9 with the /traditional/ ABI.

How wrong am I?


I'm also trying to work out the correct options to be used for building libraries and a program created with a mixture of GCC versions. The reason for the mixture is that the various library producers have different sets of consumers, with different constraints on when they can change their compilers, and different degrees of keenness  to move to newer versions of GCC. The libraries also have very heavy testing requirements. The testing is all automated, but the extra machines needed to test an additional build with a different compiler can't be conjured out of thin air.

The reliable way to get everything to link seems to be:

a) All the library producers who are using a later GCC than 4.9 need to use -fabi-compat-version=2 in their build options. That means that they produce aliases for the default GCC 4.8 (actually 3.2 to 4.9) ABI.

b) The consumer needs to use -fabi-version=2 -fabi-compat-version=2 in their build options, so that they mangle to ABI 2 standards, and link to ABI 2 symbols.

c) In the future, the consumer needs to pick a new -fabi-compat-version=N value, which implies some minimum standard of GCC that they need the libraries they consume to be built with, and get the library suppliers to use that in place of -fabi-compat-version=2. Does that make sense?

Is it possible to use more than one -fabi-compat-version=N option, to get several sets of aliases?

Thanks very much,

--
John Dallman
-----------------
Siemens Industry Software Limited is a limited company registered in England and Wales.
Registered number: 3476850.
Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD.

Re: Trying to understand the -fabi-version=n and -fabi-compat-version=n options

[Jason Merrill]

On 11/26/19 7:54 AM, Dallman, John wrote:
> I'm employed by a company that produces libraries for mathematical modelling. I'm doing this on CentOS 7.x with its bundled GCC 4.8. One of the consumers of my libraries (and many other libraries) wants to start using GCC 7.3, and later, GCC 9.2. They're worried about C++ linkage compatibility, and we don't agree over the interpretation of the GCC manual's documentation of  the -fabi-version=n and -fabi-compat-version=n options. We aren't having a fight about this, but I need to sort it out.
> 
> So I'm hoping someone can check my reasoning. I'm having to reason, because I don't have ready access to a system with anything later than GCC 4.8 on it.
> 
> I'm looking at https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc.pdf, pp. 44-45. My consumer wants to use the options:
> 
>         -fabi-version=7 -fabi-compat-version=2
> 
> Which they think says "behave just like 4.8". However, I think that says something a bit different:
> 
> 1. Compile code as if the compiler were GCC 4.8, doing the mangling with the /new/ ABI of GCC 4.8.
> 
> 2. Provide aliases for symbols the compiler creates, as if it were GCC 3.2 to 4.9 with the /traditional/ ABI.
> 
> How wrong am I?

You are correct.

> I'm also trying to work out the correct options to be used for building libraries and a program created with a mixture of GCC versions. The reason for the mixture is that the various library producers have different sets of consumers, with different constraints on when they can change their compilers, and different degrees of keenness  to move to newer versions of GCC. The libraries also have very heavy testing requirements. The testing is all automated, but the extra machines needed to test an additional build with a different compiler can't be conjured out of thin air.
> 
> The reliable way to get everything to link seems to be:
> 
> a) All the library producers who are using a later GCC than 4.9 need to use -fabi-compat-version=2 in their build options. That means that they produce aliases for the default GCC 4.8 (actually 3.2 to 4.9) ABI.
> 
> b) The consumer needs to use -fabi-version=2 -fabi-compat-version=2 in their build options, so that they mangle to ABI 2 standards, and link to ABI 2 symbols.

-fabi-compat-version with the same version number as -fabi-version has 
no effect.

> c) In the future, the consumer needs to pick a new -fabi-compat-version=N value, which implies some minimum standard of GCC that they need the libraries they consume to be built with, and get the library suppliers to use that in place of -fabi-compat-version=2. Does that make sense?

That does make sense.  But it might be simpler for everyone to just use 
-fabi-version=2 now, and later =N, without messing with 
-fabi-compat-version.

By default, if the user specifies -fabi-version, the compiler will 
generate compatibility aliases for the most current version for 
forward-compatibility.

> Is it possible to use more than one -fabi-compat-version=N option, to get several sets of aliases?

No.

Jason

RE: Trying to understand the -fabi-version=n and -fabi-compat-version=n options

[Dallman, John]

> > 1. Compile code as if the compiler were GCC 4.8, doing the mangling with
> the /new/ ABI of GCC 4.8.
> >
> > 2. Provide aliases for symbols the compiler creates, as if it were GCC 3.2 to
> 4.9 with the /traditional/ ABI.
> >
> > How wrong am I?
>
> You are correct.

Wow!

> -fabi-compat-version with the same version number as -fabi-version has no
> effect.

Presumably, this is because -fabi-version is already producing the symbols with that mangling? Seems obvious now I look at it that way.

> That does make sense.  But it might be simpler for everyone to just use
> -fabi-version=2 now, and later =N, without messing with -fabi-compat-
> version.

OK. There ... might be issues with some of the more ego-driven groups over that.

> By default, if the user specifies -fabi-version, the compiler will generate
> compatibility aliases for the most current version for forward-compatibility.

To make sure I understand this, if I'm using a compiler whose native ABI is, say, 7, and I specify -fabi-version=2 and no -fabi-compat-version=N option, that means I get the ABI 2 versions of the symbols, from the option, and the ABI 7 versions of the symbols from this default?

> > Is it possible to use more than one -fabi-compat-version=N option, to get
> several sets of aliases?
>
> No.

Didn’t think so.

Thanks very much,

--
John Dallman
-----------------
Siemens Industry Software Limited is a limited company registered in England and Wales.
Registered number: 3476850.
Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD.

Re: Trying to understand the -fabi-version=n and -fabi-compat-version=n options

[Jason Merrill]

On Wed, Nov 27, 2019 at 5:10 AM Dallman, John <john.dallman@siemens.com>
wrote:

> > > 1. Compile code as if the compiler were GCC 4.8, doing the mangling
> with
> > the /new/ ABI of GCC 4.8.
> > >
> > > 2. Provide aliases for symbols the compiler creates, as if it were GCC
> 3.2 to
> > 4.9 with the /traditional/ ABI.
> > >
> > > How wrong am I?
> >
> > You are correct.
>
> Wow!
>
> > -fabi-compat-version with the same version number as -fabi-version has no
> > effect.
>
> Presumably, this is because -fabi-version is already producing the symbols
> with that mangling? Seems obvious now I look at it that way.
>

Though actually, given the default behavior mentioned below, this will have
the effect of preventing compatibility aliases.

> That does make sense.  But it might be simpler for everyone to just use
> > -fabi-version=2 now, and later =N, without messing with -fabi-compat-
> > version.
>
> OK. There ... might be issues with some of the more ego-driven groups over
> that.
>
> > By default, if the user specifies -fabi-version, the compiler will
> generate
> > compatibility aliases for the most current version for
> forward-compatibility.
>
> To make sure I understand this, if I'm using a compiler whose native ABI
> is, say, 7, and I specify -fabi-version=2 and no -fabi-compat-version=N
> option, that means I get the ABI 2 versions of the symbols, from the
> option, and the ABI 7 versions of the symbols from this default?
>

Correct.

Jason