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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux