| |||||||||||||
The kernel and the C library as a single projectThe kernel and the C library as a single projectPosted Nov 30, 2010 23:15 UTC (Tue) by madscientist (subscriber, #16861)In reply to: The kernel and the C library as a single project by gerdesj Parent article: The kernel and the C library as a single project
Most likely nix just has a longer memory than you :-). I, too, remember when upgrading libc was a major cause of hair lossage and nail-biting.
But, I've not had any problems in probably 10 years or so... and I never shy away from an upgrade when it's offered to me. Modern distros definitely do this right.
(Log in to post comments)
The kernel and the C library as a single project Posted Dec 1, 2010 9:44 UTC (Wed) by cate (subscriber, #1359) [Link]
glibc learned how to make stable ABI, so now (last 10-12 years) upgrades are easy. IIRC the big improvement was to reserve extra space for structures, to allow library improvement without breaking ABI. (but wasting some more memory)
Probably also the c compiler is more conservative between ABI and optimisation. Actually c++ ABI is not so stable, but this cause less problem: init will anyway start, as well the essential things, thus allowing restoring systems.
BTW: libc upgrades was a nightmare because LILO cannot boot an old library, and live CD were non existent.
The kernel and the C library as a single project Posted Dec 1, 2010 16:30 UTC (Wed) by nix (subscriber, #2304) [Link]
The worry here is not 'the ABI breaks'. The worry here is 'it compiled, but if you run it it is too buggy to run significant programs without crashing'. Anything from miscompilation to buggy toolchains to general build environment problems to installation problems to a buggy glibc can do this.
The reason why glibc works when distros package it is because they take a lot of care, because they run 'make check', and because they know from experience which longstanding test failures indicate real problems. 'make check' takes, oh, half an hour on a fast Nehalem. This is not something that would add only a small amount of time to a kernel build!
The kernel and the C library as a single project Posted Dec 3, 2010 21:07 UTC (Fri) by Darkmere (subscriber, #53695) [Link]
A few Gentoo users got bit by that by trying out the gold linker. When you end up with a 64bit linker that dumps core when linking something major, like gcc, you have a somewhat usable but ultimately badly broken system.
So yeah, infrastructure upgrades like bash, glibc, gcc, binutils, python make us all _very very_ concerned. It may not be noticable at first, but if it causes bad code generation or breaks on non-trivial things, you end up with a nightmare to recover.
The kernel and the C library as a single project Posted Dec 4, 2010 19:38 UTC (Sat) by nix (subscriber, #2304) [Link]
Indeed Fedora just got hit with a mass rebuild due to just such a codegen bug in GCC's 4.5 branch (never released, but Fedora update periodically to tip-of-branch rather than using releases, so they were hit, and had to rebuild everything built with the buggy compiler).
The kernel and the C library as a single project Posted Dec 1, 2010 11:17 UTC (Wed) by NAR (subscriber, #1313) [Link]
Hmm, I think it wasn't that long ago when glibc broke (OK, exposed an already exiting bug in) flash on Fedora...
The kernel and the C library as a single project Posted Dec 1, 2010 14:07 UTC (Wed) by madscientist (subscriber, #16861) [Link]
Meh. A non-working flash definitely does not qualify for my definition of hair pulling or nail-biting. Does your system boot without having to get out a boot disk, mount your root partition, and do major surgery? Then you're good.
The kernel and the C library as a single project Posted Dec 3, 2010 9:47 UTC (Fri) by job (guest, #670) [Link]
Indeed.
Another thing that causes hair pulling but should be fairly straightforward is executable file format migrations. _Every_time_ that has caused problems.
;-)
|
|||||||||||||