Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[Anthony G. Basile]

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    : blueness@g.o
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA