LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - General
User Name
Password
Linux - General This Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.

Notices


Reply
  Search this Thread
Old 08-31-2005, 01:18 PM   #1
JCipriani
Member
 
Registered: Aug 2005
Location: Pittsburgh, PA, USA
Distribution: Redhat 9, OS X 10.4.x, Win2K
Posts: 85

Rep: Reputation: 15
Regarding distribution + kernel version + gcc version + glib version.


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
 
Old 08-31-2005, 01:32 PM   #2
jailbait
LQ Guru
 
Registered: Feb 2003
Location: Virginia, USA
Distribution: Debian 12
Posts: 8,333

Rep: Reputation: 547Reputation: 547Reputation: 547Reputation: 547Reputation: 547Reputation: 547
"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
 
Old 09-01-2005, 12:07 PM   #3
JCipriani
Member
 
Registered: Aug 2005
Location: Pittsburgh, PA, USA
Distribution: Redhat 9, OS X 10.4.x, Win2K
Posts: 85

Original Poster
Rep: Reputation: 15
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
 
Old 09-01-2005, 01:01 PM   #4
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 10,599
Blog Entries: 4

Rep: Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905
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) { }

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?

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! 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.

Last edited by sundialsvcs; 09-01-2005 at 01:03 PM.
 
Old 09-01-2005, 01:08 PM   #5
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 10,599
Blog Entries: 4

Rep: Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905
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.)

Last edited by sundialsvcs; 09-01-2005 at 01:18 PM.
 
Old 09-01-2005, 02:11 PM   #6
jailbait
LQ Guru
 
Registered: Feb 2003
Location: Virginia, USA
Distribution: Debian 12
Posts: 8,333

Rep: Reputation: 547Reputation: 547Reputation: 547Reputation: 547Reputation: 547Reputation: 547
"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
 
Old 09-01-2005, 11:22 PM   #7
Vgui
Member
 
Registered: Apr 2005
Location: Canada
Distribution: Slackware
Posts: 496

Rep: Reputation: 31
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
 
Old 09-02-2005, 12:12 AM   #8
JCipriani
Member
 
Registered: Aug 2005
Location: Pittsburgh, PA, USA
Distribution: Redhat 9, OS X 10.4.x, Win2K
Posts: 85

Original Poster
Rep: Reputation: 15
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
 
Old 04-19-2008, 02:54 PM   #9
HellesAngel
Member
 
Registered: Jun 2007
Posts: 84

Rep: Reputation: 15
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?
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Kernel version Source Version mismatch after recompile chuckleberry Linux - Software 1 06-20-2005 06:37 PM
Find out distribution + version (NOT: kernel version!) Tajci Red Hat 5 06-08-2005 03:17 PM
redhat fedora gcc version (compiled for 2.4.20) doesn't match kernel version 2.4.22 start1000 Linux - Software 0 03-16-2004 08:17 PM
Xfree prob radeon.o kernel module version is 1.1.1 but version 1.5.0 or newer needed. jimdaworm Slackware 0 10-01-2003 06:27 PM
Sample Driver Module incompatibility with Kernel version (or gcc version) jvs Linux - General 1 06-07-2002 01:40 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - General

All times are GMT -5. The time now is 03:04 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration