[gentoo-portage-dev] Pre RFC on RFC: Add compiler information to exported a Package Manger's Cached Information.

[Anthony G. Basile]

Hi everyone,

I'm not sure about the following RFC which I was thinking of sending out 
to gentoo-dev@ but I think I want to bounce off the portage developers 
first for opinions.  So I guess this is a Pre-RFC to an RFC.


RFC: Add compiler information to exported a Package Manger's Cached 
Information.

Hi everyone,

I'd like to propose adding compiler information to portage's VDB on a 
per package basis so that we record the version of the compiler a 
package is built with.  The motivation and details of what is to be 
cached and exported (as per GLEP 64) I spell out below.  The 
implementation specific are left to the package maintainers.

Currently we cache dynamic linkage information about a package's 
linkable and executable objects so we can obtain a dependency graph 
connecting shared objects to the shared objects and executables that 
consume them.  This is useful for deciding what packages need to be 
rebuilt when a library package is updated that breaks backwards 
compatibility.

Recently the portage team expanded the cached linkage information to 
include multilib ABI identifiers to distinguish between different 
executable ABIs present on a system. [1,2]   Since the consumer of a 
library can only link against a library file of the same ABI, this 
information is necessary to properly construct the dependencies.

I propose extending this to include the ABI information for C++ 
libraries.  While C++ ABIs are of a different quality than the 
executable ABIs of a multilib system, the dependency issue is the same: 
the consumer of a library can only link against a library file of the 
same ABI.  Differences in C++ ABIs arrise because there is no guaranteed 
compatibility between shared and executable objects built under 
different C++ standards. [3]  Also, there is no guaranteed ABI 
compatibility even with the same standard when built with different 
versions of GCC differing in minor bumps. [4]  Since in Gentoo we allow 
users to supply their own CFLAGS/CXXFLAGS, thus specifying the C++ 
standard via the -std= flag, and because we allow them to switch between 
version of compiler and even between different compilers, we introduce 
the possibility of breakage due to differing C++ ABIs.

While changes in ABI are normally reflected in changes in the SONAME of 
the library, GCC upstream is not willing to do so for libstdc++ for 
other design reasons [4].  So to identify possible mismatches in C++ 
ABIs, it is necessary to record any user supplied CFLAGS/CXXFLAGS which 
change the default C++ standard  as well as the compiler used and its 
version.  The flags are already cached in VDB and can be compare to the 
compiler's default c++ standard obtained from `$CC -x c++ -E -P - <<< 
__cplusplus`.  Thus only the compiler and its version need to be added 
to VDB cache.  This should be done on a per package bases in 
VDB/<category>/<package>/COMPILER.  The contents of this file are to be 
parsed from the output of the first line of `$CC --version` of the 
compiler used to build the package.  The format should be as follows:

<compiler name> <version> <optional information>

eg. "clang 3.3" or "gcc 4.8.3 (Gentoo Hardened 4.8.3 p1.1, pie-0.5.9)"

Per GLEP 64, this information should be made available for utilities to 
help identify C++ ABI mismatches.

Finally, a limitation of the above should be noted.  Since the 
CFLAGS/CXXFLAGS cached are only those supplied by the user, it does not 
cover situations where the package build system or ebuild supply their 
own -std= flag.  Since this information cannot and should not be cached 
by the package manager, utilities used to find any mismatches in C++ ABI 
must provide for this intelligence.


Refs.
[1] https://bugs.gentoo.org/show_bug.cgi?id=534206.
[2] 
http://cgit.gentooexperimental.org/proj/portage.git/commit/?id=f1c1b8a77eebf7713b32e5f9945690f60f4f46de
[3] This can lead to breakage between libraries and their consumers. 
For example,
see https://bugs.gentoo.org/show_bug.cgi?id=513386.
[4] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758.  "It is totally 
unsupported
(and unlikely to work) to mix C++11 code built with GCC 4.x and 4.y, for 
any x!=y"
The same incompatibilities may be introduced by clang as well.



-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
[phone]