I'm currently running RedHat 9.0, with kernel version 2.4.20-31.9, glibc version 2.3.2-27.9.7, and gcc 3.2.2, which seems to be the "Red Hat Linux 3.2.2-5" version of gcc.

Today I thought that I would update glibc to 2.3.5, the newest version. Much to my surprise, there is no RPM for any versions of glibc for redhat 9 out there past 2.3.2-27.9.7. Because of this, I am hesitant to build glibc from source and install it.

This leads me to my question. I am completely confused as to the ties between Linux distributions, kernel versions, and C compiler and glibc versions. In my head, I can't understand why there would be a connection. For starters, how does the kernel version relate to the specific Linux distribution that I have? Is kernel version 2.4.20 -only- the RedHat 9 kernel? Or is a RedHat 9 system with a 2.6 kernel conceivably possible? Fedora, and SuSE, they both seem to have 2.6 kernels. Is it the distribution that defines the kernel version or is the specific kernel on the system completely unrelated to the distribution that you actually have (i.e. is it possible to run any kernel version with any Linux distribution)?

What about glibc? Why is it that there is no glibc versions newer that 2.3.2 for RedHat 9? This question stems from the fact that I simply don't know why it is that glibc versions are tied to distribution/kernel versions. On top of this, is it really the case that glibc 2.3.2 doesn't "work" with distributions newer than RedHat 9? Or is it more accurate to say that glibc 2.3.2 doesn't work with kernels newer than 2.4.20? I don't know what the limiting factor is here.

What about gcc? I wanted to get the newest version of GCC (4.0.1) I believe. But I can't find it for RedHat 9... I found it for Fedora 4 though. Once again, does that mean that GCC 4.0.1 somehow does not work with distributions newer than RedHat 9? Or is it that it doesn't work with kernels newer than 2.4.20? Or is it that it doesn't work with glibc newer than 2.3.2, which in turn means that it does not work on any system that can't be given a glibc newer than 2.3.2 (for whatever reason, I don't know).

In general, I don't understand how these four things are connected, if they are connected at all. To somebody that doesn't understand this, it does not seem logical that you could not use the newest possible C/C++ compiler on your machine. But I know there has to be a good reason.

Thanks!
Jason Cipriani

jailbait

08-31-2005 01:32 PM

"Is it the distribution that defines the kernel version or is the specific kernel on the system completely unrelated to the distribution that you actually have (i.e. is it possible to run any kernel version with any Linux distribution)?"

The kernel version is pretty much independent of the distribution. I usually upgrade kernels several times per SuSE release. I have never tried to downgrade kernels. Within reason I think that should usually work too.

"What about glibc?"
"What about gcc?"

There is a stong interdependency between glibc and gcc. You have to run matching sets and usually you have to change both togather. There are also a few other programs that happen to be dependent on the latest features in glibc and they also are glibc version dependent. This means that when you change glibc/gcc you also discover several other programs that have to be changed. I changed glibc/gcc once and my opinion is that it is easier to install a later version of SuSE than to change glibc/gcc. glibc/gcc is very much tied to distribution release but rarely has anything to do with the kernel version.

-----------------------------
Steve Stites

JCipriani

09-01-2005 12:07 PM

Thanks for your reply. So just to get this straight, the kernel version itself is not directly tied to the Linux distribution, although the distribution may ship with a some binaries and specific tools that do rely on specific kernel versions. GCC and glibc are connected, but upgrading glibc is difficult because the stuff that ships with the distribution was built against a specific version of glibc and so changing the glibc version could and probably would lead to a lot of problems.

Jason

sundialsvcs

09-01-2005 01:01 PM

If you're thinking of doing anything to glibc, start by reading this tutorial. Read it thoroughly.Print it and read it again: while (true) { :study: }

In order to update glibc you first must update your kernel to a 2.6 version, or you will not be able to compile because glibc now uses the "New Posix Threading Library (NPTL)" instead of "LinuxThreads." Yes, you will not be able to compile glibc, and no, there is no way around it.

Fortunately, if you are feeling rather adventurous, you can compile a 2.6 kernel using the 2.4 compiler. You will need to do some adjustments to the startup sequence such as described here.

Still with me? :cool:

Now you can proceed to upgrade, first gcc then glibc, and it would be a go-o-o-ood idea to have a nice, fresh, bootable CD-ROM ready at this step.

The basic issue is this: most of the components of the system rely upon glibc in that, if a usable copy of that library cannot be found, they won't run. Even simple stuff: try ldd /bin/bash, which is your shell. Or how about ldd /bin/cp. Without libc.so.6, those programs won't run! :cry: This is why you need to have a back-away strategy: you could wind up with a system that is, if not unbootable, is certainly unusable.

Doesn't have to happen... didn't happen for me... but Be Prepared.

sundialsvcs

09-01-2005 01:08 PM

A distribution is one vendor's convenient and complete packaging of a Linux configuration that can be expected to "boot up and run" on almost anything. The necessary binary components have been pre-compiled by the distribution vendor.

So, the distribution vendor chooses which kernel-release to include in their distribution, and they likewise choose how to compile it, and then they go off and do that (chugga, chugga, chugga...), and finally they include in their distribution (whether or not you choose to install them) the actual source-materials that they used. From time to time they may ship out an update which replaces one of these parts of the installed system, e.g. to fix a security issue. You can, if you know what you are doing, recompile the kernel or other stuff that was sent to you by the distro vendor, to remove things that you do not need or to make it run more efficiently on your hardware.

The kernel is that part of the Linux system which is resident in-memory at all times (and/or consists of removable modules), which controls the physical hardware: CPU, memory, and devices.

The kernel consists of C and Assembler code and is built using a C-compiler such as gcc. None of that code may include library (glibc) routines, because the library is not present in kernel-space.

Note that it does not take any special privileges to build the kernel. The kernel can be built, and should be built, by an ordinary, non-privileged user. root privileges are only needed to install these things.

The gcc compiler is actually a suite of compilers, available for several different machine-architectures and pretty-much standard in the Linux world.

The glibc library is a library of routines upon which most (not all...) programs that were compiled using gcc depend. (Those that were compiled "static" do not reference glibc.)

jailbait

09-01-2005 02:11 PM

"Thanks for your reply. So just to get this straight, the kernel version itself is not directly tied to the Linux distribution, although the distribution may ship with a some binaries and specific tools that do rely on specific kernel versions. GCC and glibc are connected, but upgrading glibc is difficult because the stuff that ships with the distribution was built against a specific version of glibc and so changing the glibc version could and probably would lead to a lot of problems."

Yes, exactly.

--------------------------------
Steve Stites

Vgui

09-01-2005 11:22 PM

As another note, don't even touch upgrading gcc or glibc unless you really know what you are doing. I borked a system that way :)

JCipriani

09-02-2005 12:12 AM

Thanks for your help, jailbait, and everybody else for the replies. I went through that tutorial, sundialscvs; it's pretty informative, I'll have to keep that one bookmarked ;)

Well, anyways, I'm not going to mess with it. I thought it would only be sort of a pain in the arse but it's actually a little more than "sort of". Oh well, at least I learned something about it all.

Jason

HellesAngel

04-19-2008 02:54 PM

So upgrading isn't advised, what other options are there?

After a short while of poking around threads like this it seems those who know advise those of us who don't know not to go fiddling around with these libraries. My main computer is running SuSE Linux 10.0 which, up to recently, has suited me just fine.

Now increasingly I'm running into the problem that all the software I want to run appears to need libraries this computer doesn't have. Trust me, I don't want to upgrade these libraries, typically glibc and glibc2, I barely even want to know what they are, but what I do want is to install a newer Gimp or whatever that may fix the bug that's irritating the hell out of me. A friend offered false hope by saying I should not rely on RPMs for these applications but go for source and recompile, that way the binaries will match my system but alas it is not always the case.

That's a lot of text, but what other options are open? This really seems to be the bane of a Linux user's existence, and I've had several examples where I've been forced to give up trying to run an application as my computer is running an older Linux version. Surely this can't be the end?