Gentoo Archives: gentoo-dev

From: Francesco Riosa <vivo75@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc
Date: Tue, 25 Apr 2017 18:38:39
Message-Id: d6d323e7-9287-c129-5d0c-cfc25454dcd3@gmail.com
In Reply to: Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc by Guilherme Amadio
1 On 25/04/2017 18:44, Guilherme Amadio wrote:
2 > On Tue, Apr 25, 2017 at 11:26:16AM -0500, William Hubbs wrote:
3 >> On Mon, Apr 24, 2017 at 07:59:53PM +0200, Guilherme Amadio wrote:
4 >>> I would rather prefer to keep essential development tools in tree.
5 >>> GCC is not only used as system compiler, but also for development.
6 >>> I already had problems before with CMake being aggressively removed,
7 >>> so I couldn't just install CMake 3.5.2 to test something that got
8 >>> broken with the latest CMake (3.7.2 at the time).
9 >>>
10 >>> For things like autotools, CMake, compilers, etc, I would like to
11 >>> see at least the latest release of the previous major version (e.g.
12 >>> CMake 2.8), and the last few latest releases from the current major
13 >>> version (e.g. CMake 3.{5,6,7}). Similarly for essential libraries,
14 >>> as in prefix you may be somewhat limited by the host (think macOS),
15 >>> so removing old ebuilds aggressively breaks stuff. I think this was
16 >>> the case with clang before, where we needed 3.5 and that got removed,
17 >>> so bootstrapping on macOS was broken for sometime.
18 >> That's completely reasonable. My concern is that we have the following
19 >> versions of gcc in the tree:
20 >>
21 >> gcc-2.95.3-r10
22 >> gcc-3.3.6-r1
23 >> gcc-3.4.6-r2
24 >> gcc-4.0.4
25 >> gcc-4.1.2
26 >> gcc-4.2.4-r1
27 >> gcc-4.3.6-r1
28 >> gcc-4.4.7
29 >> gcc-4.5.4
30 >> gcc-4.6.4
31 >> gcc-4.7.4
32 >> gcc-4.8.5
33 >> gcc-4.9.3
34 >> gcc-4.9.4
35 >> gcc-5.4.0
36 >> gcc-5.4.0-r3
37 >> gcc-6.3.0
38 >>
39 >> Under your proposal, I guess we would just have gcc-5.4.0-r3, gcc-4.9.4
40 >> and maybe gcc-3.4.6-r2 and *definitely maybe* gcc-2.95.3-r10. Is this
41 >> correct?
42 > I'm not saying we should cut down to the set of versions I mentioned.
43 > I think it's totally fine to have all the gcc versions above in the tree.
44 > What I want to avoid is having less than what I said due to aggressive
45 > removal of older versions, at least for critical packages like the toolchain
46 > and related tools. So, I'd be happy with the set below for gcc, for example:
47 >
48 >> gcc-4.4.7
49 >> gcc-4.7.4
50 >> gcc-4.8.5
51 >> gcc-4.9.4
52 >> gcc-5.3.0
53 >> gcc-5.4.0-r3
54 >> gcc-6.3.0
55 > However, it doesn't hurt to have the older 3.x and 2.95 versions in case
56 > someone needs to compile, say, software that was developed a long time
57 > ago and doesn't compile anymore with the latest compilers.
58 >
59 last time I've checked (year 2010?) gcc-2.95 was impossible to emerge
60 with a newer version of gcc.
61 gcc-3.4.6 (I'm a bit surprised) _can_ be compiled by gcc-6.3
62 USE="-* nptl" emerge -1 -a --buildpkgonly =gcc-3.4.6-r2
63 but it was released March 06, 2006.
64
65 IMHO who need these old versions of gcc for good reasons is able to use
66 $preferred_search_engine to find them, if toolchain overlay can be
67 resumed to host those.
68 Of the fairly extensive (but far from complete) subset of gentoo tree
69 installed on my machines only Nvidia/cuda stuff require gcc older than 5
70 and nothing require something older than 4.9
71
72 my vote would be keep:
73 gcc-4.{8.5,9.4}
74 gcc-5.4
75 gcc-6.3
76
77 and call it northern emisphere spring cleaning (NESC)
78
79 regards,
80 Francesco