On Sunday 21 December 2008 22:42:15 Jeff Cranmer wrote: > On Sunday 21 December 2008 03:28:09 pm Justin wrote: > > Jeff Cranmer schrieb: > > > I'm afraid you'll need to be a little more specific on the accept > > > keywords > > > > reinstall and never change this variable. Stick to the many guides out > > there. Your system is broken and fixing takes the same effort than > > reinstalling. > > Except reinstalling raises the specter of losing all my key data. The > guides are written for a blank system. That is not what I have. The > problem is with glibc. Why can't I fix glibc and then to an emerge -eav > from there?
Because to do that you need to rip out the thing that everything else on your system depends on. I don't know you at all so to explain how this works I have to make some assumptions - like that you are intelligent enough to know how to drive gentoo but don't necessarily know how the toolchain and basic libraries work. This explanation is not completely 100% correct, but it will serve to illustrate the major points. glibc is the most basic library you have on the system. Everything links into it except glibc itself. It provides all the functions used by the C language for example. Programs by and large do not communicate directly with the kernel, they interface with glibc for that. glibc in turned installed a whole heap of header files on your system, these header files contain definitions of what functions and data is available, but do not contain any code. When you compile other programs for use, the compiler examines these header files to find out how to use the data and functions that glibc provides. So far, this is not any different to any other library for any other language you might have. However, glibc is special in that everything uses it for basic functions, like how to open a file or socket, how to send text to the terminal, etc. If those definitions change, or if an upgraded version of glibc provides new fancy ways to do old things, the compiler is liable to pick this up and use it, perhaps you even used gcc to compile a new gcc. Now you come along, rip out glibc and downgrade it. Basic, vital programs (like gcc and cp) try to use the glibc library as they were compiled to do, and find something different there. Oops - disaster. Remember that a compiled program does not by and large adapt itself at run time to what it finds on the system. It was compiled to use a certain library and expects to find that library in exactly the same it was in when the program was compiled. If you change stuff - well, you are the human so you get to fix it. This is usually possible provided that your basic tools still work. Except that to fix a broken glibc you need a working glibc and that is the very thing you do not have anymore. Now, if you upgraded glibc then immediately downgraded it, you would probably get away with it. Or, if nothing you built in the interim uses any changes in the new glibc, you would get away with that too. The developers cannot guarantee this, cannot write any program that is certain to help you out, and have no way to help you identify issues you might encounter after the fact. They simply will not help you and will tell you to build a new foot seeing as you were the one that shot the old one off :-) One possible solution is for someone who is using a similar configuration to what you used to have, to mail you a binary tarball of their glibc. You would boot off a LiveCD, mount your current system and untar that glibc. Then reboot, and cross fingers. You would still then have to get up close and personal with revdep-rebuild to make sure nothing was still broken, and there's a good chance you'd have that same kind soul also mail you a binary gcc, most of the toolchain and probably coreutils as well. When that's done, I suspect you'd likely run 'emerge -e world' as well. See that last sentence? Apart from 20 or so shell commands you do not have to run, how is it different from doing a reinstall anyway? It's no different in any meaningful way, so rather save yourself the bother of all that tedious mucking about with binary packages and toolchains; and just do a reinstall. Before reinstalling, make copies of all your important config files so that you can put them back when the reinstall is complete. If you were awake in class and put your /home in a separate partition like the teacher told you to do, simply do not mount it during the reinstall and mount it at first reboot (make sure you re-use the same UID for yourself when reinstalling....) So that's the easy explanation of why a glibc downgrade is not supported and why the devs do everything they can to make it not possible to even try. If none of this is new to you, well then hopefully others reading this have some of their questions answered. -- alan dot mckinnon at gmail dot com
