1 |
Hi everyone, |
2 |
|
3 |
I'm not sure about the following RFC which I was thinking of sending out |
4 |
to gentoo-dev@ but I think I want to bounce off the portage developers |
5 |
first for opinions. So I guess this is a Pre-RFC to an RFC. |
6 |
|
7 |
|
8 |
RFC: Add compiler information to exported a Package Manger's Cached |
9 |
Information. |
10 |
|
11 |
Hi everyone, |
12 |
|
13 |
I'd like to propose adding compiler information to portage's VDB on a |
14 |
per package basis so that we record the version of the compiler a |
15 |
package is built with. The motivation and details of what is to be |
16 |
cached and exported (as per GLEP 64) I spell out below. The |
17 |
implementation specific are left to the package maintainers. |
18 |
|
19 |
Currently we cache dynamic linkage information about a package's |
20 |
linkable and executable objects so we can obtain a dependency graph |
21 |
connecting shared objects to the shared objects and executables that |
22 |
consume them. This is useful for deciding what packages need to be |
23 |
rebuilt when a library package is updated that breaks backwards |
24 |
compatibility. |
25 |
|
26 |
Recently the portage team expanded the cached linkage information to |
27 |
include multilib ABI identifiers to distinguish between different |
28 |
executable ABIs present on a system. [1,2] Since the consumer of a |
29 |
library can only link against a library file of the same ABI, this |
30 |
information is necessary to properly construct the dependencies. |
31 |
|
32 |
I propose extending this to include the ABI information for C++ |
33 |
libraries. While C++ ABIs are of a different quality than the |
34 |
executable ABIs of a multilib system, the dependency issue is the same: |
35 |
the consumer of a library can only link against a library file of the |
36 |
same ABI. Differences in C++ ABIs arrise because there is no guaranteed |
37 |
compatibility between shared and executable objects built under |
38 |
different C++ standards. [3] Also, there is no guaranteed ABI |
39 |
compatibility even with the same standard when built with different |
40 |
versions of GCC differing in minor bumps. [4] Since in Gentoo we allow |
41 |
users to supply their own CFLAGS/CXXFLAGS, thus specifying the C++ |
42 |
standard via the -std= flag, and because we allow them to switch between |
43 |
version of compiler and even between different compilers, we introduce |
44 |
the possibility of breakage due to differing C++ ABIs. |
45 |
|
46 |
While changes in ABI are normally reflected in changes in the SONAME of |
47 |
the library, GCC upstream is not willing to do so for libstdc++ for |
48 |
other design reasons [4]. So to identify possible mismatches in C++ |
49 |
ABIs, it is necessary to record any user supplied CFLAGS/CXXFLAGS which |
50 |
change the default C++ standard as well as the compiler used and its |
51 |
version. The flags are already cached in VDB and can be compare to the |
52 |
compiler's default c++ standard obtained from `$CC -x c++ -E -P - <<< |
53 |
__cplusplus`. Thus only the compiler and its version need to be added |
54 |
to VDB cache. This should be done on a per package bases in |
55 |
VDB/<category>/<package>/COMPILER. The contents of this file are to be |
56 |
parsed from the output of the first line of `$CC --version` of the |
57 |
compiler used to build the package. The format should be as follows: |
58 |
|
59 |
<compiler name> <version> <optional information> |
60 |
|
61 |
eg. "clang 3.3" or "gcc 4.8.3 (Gentoo Hardened 4.8.3 p1.1, pie-0.5.9)" |
62 |
|
63 |
Per GLEP 64, this information should be made available for utilities to |
64 |
help identify C++ ABI mismatches. |
65 |
|
66 |
Finally, a limitation of the above should be noted. Since the |
67 |
CFLAGS/CXXFLAGS cached are only those supplied by the user, it does not |
68 |
cover situations where the package build system or ebuild supply their |
69 |
own -std= flag. Since this information cannot and should not be cached |
70 |
by the package manager, utilities used to find any mismatches in C++ ABI |
71 |
must provide for this intelligence. |
72 |
|
73 |
|
74 |
Refs. |
75 |
[1] https://bugs.gentoo.org/show_bug.cgi?id=534206. |
76 |
[2] |
77 |
http://cgit.gentooexperimental.org/proj/portage.git/commit/?id=f1c1b8a77eebf7713b32e5f9945690f60f4f46de |
78 |
[3] This can lead to breakage between libraries and their consumers. |
79 |
For example, |
80 |
see https://bugs.gentoo.org/show_bug.cgi?id=513386. |
81 |
[4] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758. "It is totally |
82 |
unsupported |
83 |
(and unlikely to work) to mix C++11 code built with GCC 4.x and 4.y, for |
84 |
any x!=y" |
85 |
The same incompatibilities may be introduced by clang as well. |
86 |
|
87 |
|
88 |
|
89 |
-- |
90 |
Anthony G. Basile, Ph. D. |
91 |
Chair of Information Technology |
92 |
D'Youville College |
93 |
Buffalo, NY 14201 |
94 |
(716) 829-8197 |