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 |