On 12/22/14 16:37, Andreas K. Huettel wrote:
Am Montag, 22. Dezember 2014, 18:24:32 schrieb Anthony G. Basile:
Well the side effect of this is that arcane and unmaintainable bandworms
like toolchain.eclass are generated, with dozens of case distinctions
for packages that *nearly* noone needs. Yes it's fine to keep old things
for a few people, does it merit slowing everyone else down though?
Do we really need glibc 2.9_p20081201-r3, 2.10.1-r1, 2.11.3, 2.12.1-r3,
2.12.2, 2.13-r2, 2.14, 2.14.1-r2, 2.14.1-r3, 2.15-r1, 2.15-r2, 2.15-r3,
2.16.0, 2.17, 2.18-r1, 2.19, 2.19-r1, and 2.20?
I can't fully speak to this as I'm not familiar. But are you?
No, I'm not. Which is why I am asking. I'm happy to learn.
Shall I google that for you? j/k Here are the change logs ->
http://www.gnu.org/software/libc/ There are always some big ticket
items like I remember when -lrt stuff was moved into glibc or further
back when resolver stuff was moved out. Each of these changes usually
means breakage usually in terms of what breakout libraries you need and
what linker flags you need. But I can't pretend to have watched it
closely like I'm sure Mike does. I've watched musl and uclibc and just
hit up against the glibc changes as they mysteriously rain down from
Drepper.
(On a related note, do we really need gcc 2.95.3-r10, 3.3.6-r1, 3.4.6-r2,
4.0.4, 4.1.2, 4.2.4-r1, 4.3.6-r1, 4.4.7, 4.5.1-r1, 4.5.2, 4.5.3-r2,
4.5.4, 4.6.0, 4.6.1-r1, 4.6.2, 4.6.3, 4.6.4, 4.7.0, 4.7.1, 4.7.2-r1,
4.7.3-r1, 4.7.4, 4.8.0, 4.8.1-r1, 4.8.2, 4.8.3, 4.9.0, 4.9.1, and (deep
breath) 4.9.2?
Between 4.8.3 and 4.8.4 there were 80 bug fixes with a yet unknown
number of regressions. Most people that hit these kinds of problems
revert to the previous working versions.
OK, so then let's keep all 4.7.x, 4.8.x, 4.9.x, the latest stable 4.5 and 4.6,
and maybe 3.4.
And how would someone running 4.9 get to 3.4? I tested on amd64 and I
can compile any version of gcc in the tree with 4.8, except 2.95 which I
can't compile with *any* version. But that's on *amd64* I did not test
on the other arches. It would be bad if we did this and then 3.4 is not
buildable from4.8 but is from some intermediate version which we
dumped. The general testing rule for compiling gcc with gcc is two
versions back/forwards --- Ryan can correct me if he was doing something
different, but thats' what I've done for ages. So you really need to
keep that chain 4.8 -> 4.7 -> 4.6 ... -> 3.3 going.
Add to that the quantum leaps
between 4.X and 4.(X+1) with no backwards compat in abis. Plus the fact
that some sensitive software usually aimed a special chips need specific
versions and the answer is ... yes.
One of the many moments when I really wish we had gentoostats up and running.
Why not let the maintainer decide what he/she will maintain? State
exactly is broken with toolchain that needs fixing and let's fix it.
But fixing it because its aesthetically unpleasing isn't good
engineering. Like the "messy drawer" in the kitchen. Every other
drawer is nice and tidy and you marvel at its organizational beauty. So
you stuff all the ugly complexity in this one drawer. No matter how much
you try to organize that drawer, its stays messy. And here's the
thing. Its useful that way. You can't get your brain around all the
mess and so you obsess about "cleaning it up" but if you give into the
temptation, the next time you need that square ladle you dumped because
it was ugly you'll regret it.
Is it possible to emerge @system with, say, e.g. gcc-4.0 or 4.1?
From the discussions about hardened 3.x is still interesting. But how much can
you still do with it, does anyone try regularly?
Is anyone even testing 2.95 anymore?
What happened here (in part) is the way we're doing multilib is
percolating through gentoo and hitting things it doesn't mesh with
well. That's fine we have to glue things together correctly. Throwing
stuff away when it doesn't mesh is not fine when its something good.
Please explain the specific connection of this problem with multilib.
(Shouldn't you usually use the same gcc version for your whole system as far
as you can?)
Better yet, look at mgorny's ebuild approach to gcc-4.9 and you'll see
the inclusion of multilib. We want that for things like 64-bit address
space in gcc for mips -> https://bugs.gentoo.org/show_bug.cgi?id=477956
"Build sys-devel/gcc as an N64 binary on MIPS profiles with non-N64
default ABI"
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : bluen...@gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
