1 |
Hi gang. |
2 |
|
3 |
While working on getting ada related apps ready for use I stumbled upon the |
4 |
following issue. It happens that validated (read stable and verified as |
5 |
opposed to alpha-quality stuff in gcc-3.x tree) versions of gnat are based |
6 |
around older version of gcc, more specifically 2.8.1 (quite popular version |
7 |
amongst gcc-based compiler developers I might add). This means that when you |
8 |
will try to use your gcc-3.3 superoptimized set of C[XX]FLAGS for emerging |
9 |
ada pakages you will get into trouble. |
10 |
(Note that when you emerge gnat you merely get gcc-2.8.1 backend in addition |
11 |
to your existing versions. It goes into its own dir and does not even show up |
12 |
in gcc-config. Thus your regular gcc based emerges are not affected). |
13 |
|
14 |
In order to go around this some flag stripping and mapping |
15 |
(like -march={ pentium-mmx => i586 or athlon-* => i686 }) |
16 |
has to be done in the eclass common to ada-related packages. |
17 |
I highly suspect that this situation is not unique. I can myself name at least |
18 |
one more such package - gpc, which is so far mostly stable on gcc-2.95.3, |
19 |
although later alphas can be built with gcc-3.x. |
20 |
|
21 |
Thus I would like to get an estimate on how usefull it will be to package code |
22 |
stripping "modern" C[XX]FLAGS to get them in conformance with the required |
23 |
version of gcc. I envision eclass that provides (say) versionize-flags |
24 |
function and takes a single argument - two major gcc version numbers (2.8, |
25 |
2.95 or 3.x) and strips "not yet recognized" flags accordingly. |
26 |
Actually while I am on it, I think this function will be best fit into the |
27 |
existing flag-o-matic.eclass. |
28 |
|
29 |
What does everybody thinks? |
30 |
|
31 |
George |
32 |
|
33 |
|
34 |
|
35 |
-- |
36 |
gentoo-dev@g.o mailing list |