So if I upgrade glibc, the kernel won't work?
OK, I'm not really that much of an expert and I've learnt many things the hard way. So let me tell you some things from experience!
Anybody who know better please do correct me.
I started out with a Redhat 7 system, so it has a 2.2 kernel and glibc 2.1. Since then I've been doing most of my upgrades by compiling sources (its a lot more work and lot messier, but you get to learn a lot more then by just installing RPMs!)
Once I got the drivers and other kernel configuration paramaters right, I had no trouble at all. glibc worked just fine with the new kernel. My guess is that glibc talks to the kernel through traps/interrupts so unless there's a drastic change in the interface glibc wouldn't mind... and the kernel developers won't break binary compatibility unless there's an overwhelmingly strong reason to do so.
My conclusion, kernels can be upgraded pretty painlessly.
Glibc was another matter. I installed glibc 2.2.3 with the prefix /usr/local (the default) and everything seemed fine. But when I later upgraded to 2.2.5 things went nuts. I don't know what I did, but somehow the linker (ld-linux) couldn't find glibc 2.2.3 so everything I'd compiled on my system failed. When I copied ld-2.2.3.so to /lib hoping it would be found there, all of redhat's stuff (cp, ls etc!!!) stopped working. I had to boot from the rescue CD to fix that. Ultimately I ended up compiling both the glibc 2.2.3 and 2.2.5 and installing them both with /usr prefix, and everything's been working fine ever since.
My conclusion, upgrading glibc can break your system totally if you don't know that you're doing!
However there's one thing you should know... the kernel doesn't need to find glibc while its being compiled... its the other way around. Glibc is a C-callable interface to ther kernel services.
If you also want to upgrade GCC you might want to do it before glibc... the quality of code produced by the compiler won't depend much on the version of libc used by the compiler, but compiling glibc with the latest gcc might help take advantages of the latest features and optimizations.
However, use kgcc rather than gcc 3.x to compile the kernel. I remember getting a horribly broken kernel when I compiled it with 3.0.1 (iirc)
On Jun 30, 2002 at 14:00, Vinay Pai wrote:
Once I got the drivers and other kernel configuration paramaters right, I had no trouble at all. glibc worked just fine with the new kernel. My guess is that glibc talks to the kernel through
Yes, kernel upgrades are no problem.
Glibc was another matter. I installed glibc 2.2.3 with the prefix
And that's what worries me.
My conclusion, upgrading glibc can break your system totally if you don't know that you're doing!
Exactly. See, almost everything is usually compiled with dynamic library linking i.e. calls are made in your program to functions in gcc. Try compiling a simple helloworld.c using:
gcc helloworld.c
and
gcc --static helloworld.c
(I think it's "--static")
and note the difference in executable size. The latter includes most of glibc (or at least enough for stdio.h and printf) into your executable.
However there's one thing you should know... the kernel doesn't need to find glibc while its being compiled... its the other way around.
Oh? That's new.
If you also want to upgrade GCC you might want to do it before glibc... the quality of code produced by the compiler won't depend
I have to, the new glibc doesn't settle for gcc less than 2.x (x=95, I think).
However, use kgcc rather than gcc 3.x to compile the kernel. I remember getting a horribly broken kernel when I compiled it with 3.0.1 (iirc)
gcc is either fixed or it's the right way to do it now. Either way, I'll use 3.0.3 or whatever the latest is.
On Sun, Jun 30, 2002 at 02:00:15PM +0530, Vinay Pai wrote:
Glibc was another matter. I installed glibc 2.2.3 with the prefix /usr/local (the default) and everything seemed fine. But when I later upgraded to 2.2.5 things went nuts. I don't know what I did, but somehow the linker (ld-linux) couldn't find glibc 2.2.3 so everything I'd compiled on my system failed. When I copied ld-2.2.3.so to /lib hoping it would be found there, all of redhat's stuff (cp, ls etc!!!) stopped working. I had to boot from the rescue CD to fix that. Ultimately I ended up compiling both the glibc 2.2.3 and 2.2.5 and installing them both with /usr prefix, and everything's been working fine ever since.
My conclusion, upgrading glibc can break your system totally if you don't know that you're doing!
Of course, it won't help if you just upgrade your glibc. Because all programs are dynamically linked to glibc ( not all .. but almost ). So, you need to recompile them, or, in case that everything is compatible except the version numbers, create symlinks.
For the kernel .... [root@tachyon root]# file /boot/vmlinux-2.4.18-3 /boot/vmlinux-2.4.18-3: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped [root@tachyon root]#
Note: statically linked.
-
Ravindra Jaju -
Satya -
Vinay Pai