Gentoo Archives: gentoo-dev

From: George Shapovalov <george@g.o>
To: gentoo-dev@g.o
Cc: David Holm <david@×××××××××××.com>
Subject: [gentoo-dev] interest assay: eclass for stripping "modern" C[XX]FLAGS
Date: Thu, 03 Jul 2003 03:13:04
Message-Id: 200307022011.05918.george@gentoo.org
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

Replies