This is related to bug #21132 (which added LD_ASSUME_KERNEL=2.4.1 support to glibc). There are still some commercial applications that will only work with LD_ASSUME_KERNEL=2.2.5. Also, InstallAnywhere by ZeroG overrides any LD_ASSUME_KERNEL environment variable to 2.2.5 if it detects it's running on Linux (this is really dumb, and I've told ZeroG already and they'll fix it in the next release of InstallAnywhere). I can understand that adding yet one more cycle to the glibc ebuild seems like overkill, so I filed this bug as an enhancement to see what people thought. It's not difficult to maintain a seperate 2.2.5 glibc ebuild (or do it manually which is what I do now).
what glibc version are you talking about here ? we already have glibc-2.2.5 in portage ...
I don't mean glibc-2.2.5. I mean glibc built with --enable-kernel=2.2.5. This will allow the dynamic linker to find libc properly when the LD_ASSUME_KERNEL environment variable is set to 2.2.5.
if you simply change the '--enable-kernel=2.4.1' to '--enable-kernel=2.2.5' in the glibc ebuild, does it work ? i should update the ebuilds to respect EXTRA_ECONF that way you should be able to simply do `EXTRA_ECONF=--enable-kernel=2.2.5 emerge glibc` ...
That part I'm not 100% sure about. I'll do some research. It might be that a pernament change to --enable-kernel=2.2.5 would work. This should enable support for anything higher than 2.2.5 (which would include 2.4.1). According to: http://people.redhat.com/drepper/assumekernel.html 2.2.5 is different than 2.4.1 (older version of linuxthreads with fixed sized threads). But, if you look at the redhat RPM spec file the config flags between their 2.2.5 and 2.4.1 enabled versions are the exact same EXCEPT for the --enable-kernel, so it's entirely possible the glibc build itself is dependent on the --enable-kernel version option for more than just adding the ABI version note.
i dont think we should be adding that to our ebuild for everyone ... making it possible for people (such as yourself) to drop in the 2.2.5 is one thing, changing the ebuild for everyone is another
well, the latest glibc ebuild was modified to add support for 2.4.1 for everyone. Why not 2.2.5? It'll be more consistent with fedora/redhat's glibc build. [I'm not entirely certain this is a goal gentoo necessarily needs though :) ]
i'd consider 2.4.x support a little more common than 2.2.x :)
*** Bug 81756 has been marked as a duplicate of this bug. ***
what's the advantage of using "--enable-kernel=2.4.1" instead of "--enable-kernel=2.2.5"? The glibc ebuilds up to version 2.3.4.20040808 didn't use any --enable-kernel option, and that resultet in an OS ABI of 2.0.0 ! So i guess the implicit default of the --enable-kernel option is 2.0.0 and nobody complained about that, or were there any complains? # qpkg -I -v |grep glibc sys-libs/glibc-2.3.4.20040808-r1 # ldconfig -p |grep libc.so libc.so.6 (libc6, OS ABI: Linux 2.0.0) => /lib/libc.so.6
If you want to override it, youu can set LT_KERNEL_VERSION in /etc/make.conf, and it'll be used in glibc-2.3.4.20050125-r1
