Switching to kernel26 solved the problem!

Yes, it seems that the latest glibc will not work with kernel 2.4.x.

We're looking into a solution for this, though it may mean that we will not support the 2.4.x kernel series anymore.

I've been digging hard on this issue, as I really desire to run the 2.4 kernel for a particular program, on my laptop/etc.

So far, I am discovering the basics: 2.4 kernel doesn't support the new threading which is the preferred threading if you're using 2.6. It's called Native POSIX Threading Library - NPTL. 2.4 kernel supports LinuxThreads, which was the old threading library.

However, in general circumstances, it appears that glibc is supposed to be built to support both: the libraries in /lib are LinuxThreads and the ones in /lib/tls (for "thread-local storage") are for NPTL.

So here's some possiblities for what might be going wrong:

1) Somehow in this newest 2.3.5 version, the right version of those libraries is not getting chosen when the 2.4 kernel is booted, and so it's dying

2) Something fairly low-level (like init?) is compiled expressly against NPTL for some reason, so it's explicitly selecting the un-runnable library and dying

3)?

There could be many other options. I'm just using this as a way to record some of this thinking and give us a place for discussion.

Hello,

googleling something around this morning, I found this hint at http://hr.uoregon.edu/davidrl/docs/glibc.html:

<!--
Thread-local storage:
Some people have run into the following error message while building glibc:

cannot set up thread-local storage: set_thread_area failed when setting up thread-local storage

This is frequently caused by building glibc on a system running Linux 2.4 and not passing the "linuxthreads" option to the --enable-add-ons parameter. Since glibc 2.3.5 builds the new thread model by default, it will fail even if you've downloaded and prepared the glibc-linuxthreads package.
-->

So one solution to maintain kernel2.4 support in ArchLinux (if the above mentioned information is correct! I didn't check this out) would be to prepare different glibc packages for systems running 2.4 and 2.6!

Thanks for your research!

Here's the bad news: we do enable the option in our glibc build, with the flag: --enable-add-ons=linuxthreads

So it must be something more sinister.

Could it possibly be that this is a snapshot of glibc with a bug? Maybe we could try building another and see if the problem goes away? The more I read about this problem the more I begin to think that everything *should* be just working, just like it did with the previous glibc package version.. only it's not.

Here's a newer snapshot with some fedora-specific things stripped. It's also a bit smaller because the lack of duplicate libraries. Other new thing: idn support.

http://schoolbak.dyndns.org/~jan/glibc-2.3.5-7.pkg.tar.gz

If this one works fine with 2.4 kernels, it will go to testing and will go into current very shortly after that.

@paul: your guess with the buggy snapshot could be right! As I mentioned in my initial post, gdb reported an error in ld-2.3.5.so. So if everything is ok with build options, this would rather be a case for the glibc bugtracker than here!

Jan:

You are my new best friend. Seriously, though, if you have a Paypal account I'll send you, like, $50, because you've saved me tons of time.

I did a test on an updated box, and it seems to boot fine with both 2.4.31 and 2.6.13.4.

I think it's ready to go into testing; far from being rigorously tested, yet, the first looks seem to indicate that this is the fix we needed. I'll install the testing package on several of my devel machines and maybe my laptop, too, to give some better sense that this snapshot doesn't create other large issues.

Hehe, if you want to donate, donate it to archlinux, I'm sure Judd can use it to improve the hosting of archlinux.org ;)

Done.

Thanks again! I'm writing this from kernel 2.4 on my laptop, running with the new glibc. Everything seems smooth as silk so far.