glibc has a Catch-22 In It

Journal started Nov 9, 2004


So 4 days ago my copy of the C library well... glitched. Now the C library on Linux you must understand is the greater half of the operating system. It is what makes Linux POSIX compliant, what I use to do some minor, unimportant tasks such as reading and writing files, using network sockets, running programs, listing directories. Needless to say this library isn't the easiest to update, as it depends on its own mechanisms to update with. So the fact that mine bugged out, causing an important usermode kernel driver to spin and swallow 99% of my system resources, is a Very Bad Thing.

The C library is also known as glibc, even though it's in a file called libc.so.

My fault I suppose. I went and compiled a custom version of glibc. Probably ended up with a messed up ABI and everything. But the Debian glibc was just too old and obsolete; there were things I needed to do that I could not do with it. But either through hardware glitch, or something I did erroneously, it randomly decided to stop working.

No problem, I thought. I compiled glibc once, I can compile it again. How little did I know...

Here's the summary, and really all that anyone should ever have to know to realize that glibc, and therefore Linux is in Big Trouble. The current threading model works like a lightweight fork, even going so far as to separate threads into different processes. Far from just cluttering up the 'ps -a' output, it is wasteful and takes up lots of PIDs in thread-intensive applications.

More POSIX would be to have all threads for one PID have the same PID, or even better not be separate processes at all. So that's what NGTL is. Oops, sorry NGTL is deferring to the NPTL, as created by the Red Hat company, who sorta has a big say in glibc development.

New Puh Thread Library is really nice; I want it. So I got the latest form of glibc and tried to compile it. "Error! This target does not support thread-local storage," my compiler said. The latest glibc requires thread-local storage for its NPTL module. Thread local storage, or TLS is basically variables that are not shared between threads. Real rocket science, huh.

Okay, so I upgraded my compiler. Here's where it gets tricky. When you compile gcc (with gcc @.@), it is compiled against, guess what? The C library! So gcc is compiled with the current C library, and that is what determines whether or not it supports TLS.

Now, I don't have a C library that supports TLS. I'm trying to compile one that does. To compile the C library for TLS, you must have a compiler that supports TLS. And to have a compiler that supports TLS, you must compile a C library for TLS. Ouch! Catch-22! Mayday, mayday, going down, End of World full story at 11.

NPTL is pretty cool, but in its current state nobody in the world can compile glibc. That is Bad because that means the greater half of linux is therefore frozen in the last working state of glibc. And as I mentioned above that is a smaller symptom of Big Trouble.

So... I went and installed Gentoo. No more Debian. All gone buh bye. Gentoo meets my needs better anyway; I can override packages I installed myself, and it's really up to date. Plus it's smaller, faster and easier to understand. :shrugs: and... *GASP* oh my goodness, the keyboard, mouse mix-up is gone! Hooray! No more pointer jumping all around the screen while I hold down a button, randomly changing window states as it dances! :dances:


Comment
Index
Previous (Roleplay... But Nothing Happens?)
Next (Getting chroot CGI working)

(cc) some rights reserved