Using LD_ASSUME_KERNEL stops at least libc.so and libm.so from loading. if using nptl, a non-nptl libc/libm should be installed in a suitable place. On my pentuim3 box, ld-linux.so.2 looks in: /lib/tls/i686/mmx/libm.so.6 /lib/tls/i686/libm.so.6 /lib/tls/mmx/libm.so.6 /lib/tls/libm.so.6 /lib/i686/mmx/libm.so.6 /lib/i686/libm.so.6 /lib/mmx/libm.so.6 /lib/libm.so.6 /usr/lib/tls/i686/mmx/libm.so.6 /usr/lib/tls/i686/libm.so.6 /usr/lib/tls/mmx/libm.so.6 /usr/lib/tls/libm.so.6 /usr/lib/i686/mmx/libm.so.6 /usr/lib/i686/libm.so.6 /usr/lib/mmx/libm.so.6 /usr/lib/libm.so.6 and the same dirs for libc.so.6.
I've since upgraded to gcc 3.3-r1 and glibc 2.3.2-r3. This bug remains. In addition to libc and libm, at least libpthread and librt are also needed, depending on what kernel version is specified in LD_ASSUME_KERNEL.
You want non-tls libs in /lib, and tls ones in /lib/tls/. Order of search works fine in glibc-2.3.2-r[23].
> You want non-tls libs in /lib, and tls ones in /lib/tls/ OK, but the ebuilds do not do that, so the bug is still extant as a bug in the glibc ebuilds.
Its by design - else you will have to compile glibc twice. Why do you need it (meaning why is it so important that you want *everybody* else to build gcc twice every time they recompile glibc).
Everyone shouldn't have to, no, this should be an option by some sort of use variable. LD_ASSUME_KERNEL is needed for some older apps to work on an nptl system (for instance quite a few of the older loki games) and there really should be an easy way for users to set this up if they need it.
This is also causing me issues. Apps like XWT (which can be tested using this download: http://www.megacz.com/tmp/xwt.linux.gz) b0rk when they can't find /lib/tls and /lib/i686 etc.
As someone that was working to debug XWT, let me clarify. XWT is incompatible with nptl in all distributions. As a workaround, XWT *itself* sets LD_ASSUME_KERNEL in order to use the non-nptl version of glibc. Since gentoo doesn't have the non-nptl version available, xwt is guaranteed to fail.
LD_ASSUME_KERNEL is need, for example to run SAPDB or MaxDB. Since SAP and MySQL refuse to upgrade their Code to work with NPTL, i need to use LD_ASSUME_KERNEL. I would prefer the sollution with the use-flag, so that the glibc-ebuild builds a second version of glibc with Linuxthreads. Not everybody would have to build glibc twice than. Only the people who need it.
I don't need a use-flag & ebuild (but it would be very nice :-) - but the information to "just compile it twice" is not too usefull. Who knows HOWTO complie it twice to make it work? Just the steps in a small howto would help many people out there. Switching to Redhat is an option (but no real alternative). Martin Schlemmer: It looks like you know how to do it. Please, please share your knowledge with us!
I second that - I'm way stumped on this one. I tried a couple of times and each time my system stopped working - I had to reboot and restore glibc. Could someone point out how this is supposed to be possible???
I had compiled glibc on another gentoo box and copied the files from it over to my /lib/tls/. I then did an export LD_LIBRARY_PATH=/lib/tls/ to use those libraries over mine in /lib. I then tried running maya and it stopped complaing about the GLIBC_2 but it just segfaults now ! I assume its because of the way I had compiled the glibc on the other computer. I have a feeling that I compiled it with march on the other computer which is a different type them mine (athlon vs athlon-xp). so i'm going to recompile it without the optimazations and try it again, but does anyone have a better solution then this ?
i found a solution: http://forums.gentoo.org/viewtopic.php?t=96278 can someone create a ebuild file and a new USE flag: assume_kernel ?
yes, it will be useful to have this feature selectable with a use i'm experiencing similar problems with matlab
Add another vote for fixing this one...I'm having trouble with Matlab. I'll try to comprehend the fix, and gife it a shot, though. Starting license manager . . . Debug logfile = /var/tmp/lm_TMW.log /var/tmp/lm_TMW.ld: relocation error: /var/tmp/lm_TMW.ld: symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference
Got another vote for fixing this one... I'm installing Lotus Domino Server 6.5 and getting the following error: ./java -ss512k -Xoss5M -cp jhall.jar:cfgdomserver.jar:Notes.jar lotus.domino.setup.WizardManagerDomino -data /local/notesdata /opt/lotus/notes/latest/linux/serversetup: line 124: 24240 Segmentation fault ./java -ss512k -Xoss5M -cp "jhall.jar:cfgdomserver.jar:Notes.jar" lotus.domino.setup.WizardManagerDomino $datapath $1 $2 $3 $4 $5 $6 $7 $8 $9 After some research, I found that setting LD_ASSUME_KERNEL=2.2.5 would fix the problem on RH9 and other distros. When I set it in Gentoo, I get the following errors: /opt/lotus/bin/java: line 68: [: =: unary operator expected uname: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory Unknown platform stty: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory I looked further into the problem and discovered that many other enterprise-level apps such as Oracle 9i have the same problem. I don't have the liberty of going through the extra time and trouble of compiling twice--one emerge, one by hand. This Domino server is going to function in a production environment and having as standard an install as possible (that is, one that's not heavily tweaked) is important for manageability.
To reply to comment #12, you really don't need a separate USE flag for this, it should be done like that by _default_ when the 'nptl' USE flag is set. Somebody needs to submit an updated glibc ebuild.
I really don't know why the glibc ebuild should build two glibc by default. If i don't use NPTL-incompatible software, i won't need the LD_ASSUME_KERNEL stuff. I would really like this to be a separate ebuild instead of a use-flag. There are many of those backward-compatibility ebuilds like libstdc++-v3, lib-compat, ...
RedHat/Fedora does it this way on modern x86 architectures (686 and higher): The "default" glibc in /lib, contains glibc built with linuxthreads using the following options:--with-tls --without-__threads and enable-kernel=2.2.5. Then in /lib/i686 they rebuild it with the same arguments but --enable-kernel=2.4.1. Then in /lib/tls they rebuild it with nptl support basically. All the locations are in the ld.so.conf path by default, and depending on LD_ASSUME_KERNEL it'll use /lib/tls if kernel version is 2.4.20 or higher, /lib/i686 is 2.4.1 or higher or /lib for 2.2.5 or higher. This way also, /lib contains the sanest library combinations. I started hacking ebuilds. I can come up with two basic options, 1) do something similar to redhat where /lib is a sane, most compatible built glibc. This has the following benefits: a) i can boot a 2.4 kernel again with nptl used only when a support kernel version is booted. b) it's very similar to redhat/fedora which may help in compatibility c) i don't need to concern myself with /usr/lib/gconv (see my note below for more about gconv. if anyone can answer my questions that'd be great) 2) I also started on a seperate ebuild to just copy .so files to /lib/no-nptl. This has the following benefits: a) glibc is only built once for those who don't need older glibc support So the problem i have is, by default the glibc ebuild builds glibc with kernel ver 2.6.0. The way this works is that an elf note is placed on the binary with the ABI compatibility informaton (i.e. kernel version 2.6.0). it does this for all .so files built with glibc (including those in /usr/lib/gconv. i haven't figured out how the gconv modules in /usr/lib/gconv are loaded, but they won't load if your LD_ASSUME_KERNEL is set to low (which will cause problems unless option 1 is loaded, or if someone can explain to me why the ABI version note on gconv won't matter then option 2 is a solution, or if someone can explain to me how to tell whatever uses gconv to look in a secondary location for the .so files this will also work).
err. option #3 i forgot about 3) use flag in glibc package to use the option #1 style if it's used, otherwise, just work the way it currently is. I like this one, because it's an elegant solution that solves the problems inherent in option #1 and #2, but end result is, glibc's installation can be radically different on different gentoo systems (not necessarily a bad thing, and don't things on different gentoo systems tend to be radically different anyways? :) ). I'm liking this solution. I'll work on an ebuild for it tonight and try to attach it to this bug when I'm done.
Created attachment 33859 [details] ebuild to handle ldassume feature Here's the ebuild that builds glibc similar to how redhat and suse do if the nptl and ldassume use flags are set. Otherwise, it basically works like it currently does.
Created attachment 33860 [details] ldpath env.d file for nptl
just attached the ebuild and env.d file. Basically if the 'ldassume' use flag isn't set it works exactly like it does now. If it and nptl are set, it builds it similar to redhat/suse: default install of glibc uses linuxthreads and kernel ver 2.4.1 /lib/tls contains the shared libs for glibc with nptl and kernel ver 2.6.0 /usr/include/nptl contains the nptl thread headers and /usr/lib/nptl contains the nptl static libs and .so stubs. By default static binaries will use linuxthreads, and -L/usr/lib/nptl and -I/usr/include/nptl will be necessary to handle statically built nptl apps. Dynamically linked binaries work the same. Comments?
I finally got around to trying this ebuild, after i had been using the howto for doing it manually for quite a while. The ebuild's fine when I don't use the ldassume USE flag, but with it things mess up: >>> original instance of package unmerged safely. ~x86 >>> Regenerating /etc/ld.so.cache... [] bash: error while loading shared libraries: libc.so.6: cannot handle TLS data >>> sys-libs/glibc-2.3.3.20040420-r1 merged. [glibc-2.3.3.20040420-r1] bash: error while loading shared libraries: libc.so.6: cannot handle TLS data I have to remove /lib/tls from /etc/ld.so.conf to get any programs to work again, (though LD_ASSUME_KERNEL=2.4.1 allows programs to work) does anyone have any idea why the /lib/tls part is messing up? i'm on kernel 2.6.7, and nptl works fine when i compile glibc without the ldassume USE flag: getconf GNU_LIBPTHREAD_VERSION NPTL 0.61
This needs to be ported to the ebuild currently in portage. Some applications have been broken for weeks while working on other distros as we speak.
*** Bug 49751 has been marked as a duplicate of this bug. ***
Here's an interesting exert from a recent conversation I had with a colleague who works on setting up generic Linux binaries for our project. Whilst it doesn't pinpoint the exact problem, it does show that the situation is improving. Basically I could never run the Linux binary on Gentoo a while back because of this problem, but now things work flawlessly, and here was his take on it: Charlie: btw, how did you work around the LD_ASSUME_KERNEL problem? Tupshin: i didn't Charlie: you mentioned that things were "fixed" in recent glibc (?) releases Tupshin: either newer gcc or more recent glibc as fixed it...I haven't spent any time figuring out which, or why Charlie: so it's still in [our binary] (as in, if i reverted to an older gentoo system, it'd fail with that problem?) Tupshin: not necessarily...if the problem was with libc, then yes, but if the problem was with gcc, then no So either recent glibcs or recent (3.4.x) gccs have solved this problem. It would be nice to know which, as if it's gcc that is fixed then we can simply notify developers that they need to recompile their binaries with a non-broken gcc. If it's glibc, then this problem has literally "gone away" and we need to encourage people who suffer from this issue to upgrade their glibc. Does anybody know which it is? I get the impression from the comments in this thread that it's glibc that contains the fix.
This works very well in getting poorly written apps to work with NTPL compiled glibc installs. Is this something that will need to be included with glibc-2.3.4?
> Is this something that will need to be included with glibc-2.3.4? According the the latest 2.3.4 ebuild: # Minimum kernel version we support # (Recent snapshots fails with 2.6.5 and earlier) MIN_KERNEL_VERSION="2.6.5" So I'd guess that's probably not gonna happen because the entire LD_ASSUME_KERNEL idea might just stop working from glibc 2.3.4 on. :-( Don't know what the glibc people are thinking... But glibc 2.3.3 (stable) has just been released! Is the person in charge of glibc ebuilds going to look into this when writing the new ebuild for this? I'd REALLY like to see a stable glibc supporting LD_ASSUME_KERNEL on gentoo. That'd be perfect for those running Gentoo on a production environment. I still don't have the gut to try this ebuild yet because I really can't afford to break my main system! Regarding the comment of new gcc/glibc/whatever solving the problem, I tried getting the latest version of all that and modified the mono ebuild to build the daily snapshot and the mono xsp server still fails whenever a garbage collection occurs. Except that now it says sem_wait failed and quit instead of silently deadlocking. Oh cool, now you can detect that you failed but I already know that even if you don't tell me... That's a good step forward but it isn't very helpful in getting it run. I guess whether newer gcc/glibc fix the problem depends on the application. And mono is the probably most problematic application in this area. :-(
*** Bug 61128 has been marked as a duplicate of this bug. ***
I tried to use the ebuild by hand (ebuild glibc-2.3.3.20040420-r1.ebuild fetch unpack compile install) and then use LD_LIBRARY_PATH to try them out but failed. It appears that the NPTL and non-NPTL versions have different glibc version symbols! After a night of fun with objdump and readelf, I found out that the one with NPTL enabled have the GLIBC_2.3.3 symbol while the non-NPTL version only has GLIBC_2.3.2. I looked at the ebuild and some of the patches and I really don't understand why. Now that my system is already running the official 2.3.3 ebuild with nptl enabled, switching to this ebuild would be the same as a glibc downgrade and will probably cause major breakage! Anybody know how to fix this?
alright, everyone please test glibc 2.3.4.20040928. it's masked -*, but -should- have the behavior you want.
to clarify: the default behavior with USE=nptl is to build glibc twice. once with and once without nptl. to return to the old behavior you need to add nptlonly to USE, but that's not what you people here want. ;)
the 20040928 ebuild works like a charm here: overridex@nazgul ~ $ getconf GNU_LIBPTHREAD_VERSION NPTL 2.3.4 overridex@nazgul ~ $ LD_ASSUME_KERNEL=2.4.20 getconf GNU_LIBPTHREAD_VERSION linuxthreads-0.10 yay! finally :) -Dan
It works for me too (with matlab 7.0) thank you :)
could one of you do me a favor and also try booting a 2.4 kernel? if that also works as expected, then i need to do some rewrites to possibly allow 2.4 kernel users to compile this glibc, even if they wont be able to use nptl while booting a vanilla 2.4 kernel.
Seems to work fine after booting to a 2.4.x kernel, however I don't have lvm2 setup on it so I couldn't completely boot (but init ran and stuff, which it normally wouldn't on an nptl glibc...) Something possibily unrelated, with the belkin bulldog software I'm getting this error with this glibc: ./monitor: error while loading shared libraries: /lib/libNoVersion.so.1: cannot open shared object file: No such file or directory That file does indeed exist, in fact it doesn't seem like libNoVersion even existed in glibc 20040808 that I had been using, so it's a little strange - maybe i'll try the nptlonly use flag to make sure it isn't related. -Dan
I was able to get my 2U to compile this, and it works well there, but am having trouble getting the laptop to compile it. After compiling both versions, it comes to msgfmt(1), and that fails with: msgfmt -o zh_CN.mo zh_CN.po zh_CN.po:5428:17: invalid multibyte sequence zh_CN.po:5428:26: invalid multibyte sequence msgfmt: found 2 fatal errors make[2]: *** [zh_CN.mo] Error 1 make[2]: Leaving directory `/media/bay/portage/portage/glibc-2.3.4.20040928/work/glibc-2.3.3/po' make[1]: *** [po/subdir_install] Error 2 make[1]: Leaving directory `/media/bay/portage/portage/glibc-2.3.4.20040928/work/glibc-2.3.3' make: *** [install] Error 2 !!! ERROR: sys-libs/glibc-2.3.4.20040928 failed. !!! Function src_install, Line 638, Exitcode 2 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message. (-pv says: [ebuild U ] sys-libs/glibc-2.3.4.20040928 [2.3.4.20040808] -build -debug -erandom -hardened -multilib +nls +nptl -nptlonly +pic +userlocales* 0 kB ) I tried re-installing gettext (which hit some segv bug in blackdown's javac and required that I change java...); the failure remains. I upgraded gcc before testing this. Beyond that, as long as +nptl +nptlonly is the same as -nptl +nptlonly this ebuild nails it. Thanks.
2.3.4.20041006 worked on my system whithout any problems. Thanks. Just a comment: for consistence reasons shouldn't it also build the threading system of the 2.2* kernels?
I had to rsync /usr/lib/gconv from a working box to get the compile to finish, but I now have the current version on the laptop, too. The only other issue I can think of is the 32-bit libs for amd64; I don't know how those are built, but the option for nptl (ie both), nptlonly or just linuxthreads (default) should exist there, too. For the 64 bit libs I presume there is no need for anything but nptlonly, yes?
alright, marking as fixed now that 2.3.4.20041006 is keyworded as testing. i've also edited the ebuild to never delete the glibc-compat add-on, so libNoVersion.so should always be built... for anyone having problems, wait 30 minutes, re-sync, and re-emerge. if it still fails, file a new bug.
I was having some issues with the last couple of 2.3.4.200410* snapshots on my test box (NFS and Groups permissions glitches), so I decided for my workstation (which needs to be stable), I'd integrate the dual NPTL/Linuxthreads concept into the "stable" glibc ebuild (which is 2.3.3.20040420). I've got this working, as can be seen by this: # /lib/tls/libc.so.6 GNU C Library stable release version 2.3.3, by Roland McGrath et al. Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6). Compiled on a Linux 2.6.7-jrt5 system on 2004-10-11. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others NPTL 0.61 by Ulrich Drepper GNU Libidn by Simon Josefsson BIND-8.2.3-T5B NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Thread-local storage support included. Report bugs using the `glibcbug' script to <bugs@gnu.org>. # getconf GNU_LIBPTHREAD_VERSION NPTL 0.61 # LD_ASSUME_KERNEL=2.4.1 getconf GNU_LIBPTHREAD_VERSION linuxthreads-0.10 I'll attach my diffs to the glibc-2.3.3.20040420 ebuild (against the newly released -r2), in case a) anyone else wants them, and b) there is sufficient demand to push into the "stable" version (as an real -r3). This has NOT been heavily tested; it works for me, but YMMV.
Created attachment 41581 [details, diff] Patch to glibc-2.3.3.20040420 ebuild to create both NPTL and Linuxthreads GLIBC
Created attachment 41593 [details, diff] Patch to compile both NPTL and Linuxthreads versions of GlibC Just noticed a couple of errors in the previous patch, now corrected.
>>LD_ASSUME_KERNEL is needed for some older apps to work on an nptl system (for instance quite a few of the older loki games) ...and kylix which seems to use some loki code
Glibc-2.3.5 has the problem again: with kylix: $ LD_ASSUME_KERNEL=2.4.1 startdelphi /home/renato/kylix3/bin/delphi: relocation error: /home/renato/kylix3/bin/libwine.borland.so: symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference Also, if I ask for 2.4.0 i get this: $ LD_ASSUME_KERNEL=2.4.0 startdelphi /bin/bash: error while loading shared libraries: libdl.so.2: cannot open shared object file: No such file or directory Please reopen the bug.
no, unrelated re-emerge glibc-2.3.5 with USE=glibc-compat20
