Since I emerged glibc-2.3.5, Xorg doesn't start anymore with the nvidia driver, but exists with a segfault during loading the GLX extension. Using the nv driver works fine thou. Reproducible: Always Steps to Reproduce: 1. 2. 3. Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.3.5-r0, 2.6.10-gentoo-r7 i686) ================================================================= System uname: 2.6.10-gentoo-r7 i686 Intel(R) Pentium(R) M processor 2.00GHz Gentoo Base System version 1.6.11 Python: dev-lang/python-2.3.5 [2.3.5 (#1, Feb 18 2005, 16:37:26)] dev-lang/python: 2.3.5 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.9.5, 1.8.5-r3, 1.7.9-r1, 1.5, 1.6.3, 1.4_p6 sys-devel/binutils: 2.15.92.0.2-r8 sys-devel/libtool: 1.5.14 virtual/os-headers: 2.6.11 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium-m -O3 -pipe -mmmx -msse -msse2 -mfpmath=sse -fforce-addr -fomit-frame-pointer -funroll-loops -frerun-cse-after-loop -frerun-loop-opt -fal ign-functions=4" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X1 1/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-march=pentium-m -O3 -pipe -mmmx -msse -msse2 -mfpmath=sse -fforce-add r -fomit-frame-pointer -funroll-loops -frerun-cse-after-loop -frerun-loop-opt -f align-functions=4" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://sunsite.cnlab-switch.ch/ftp/mirror/gentoo ftp://sunsite.c nlab-switch.ch/mirror/gentoo" LINGUAS="zh_CN zh_TW ja ko" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X Xaw3d acl acpi alsa avi berkdb bitmap-fonts cdr clamav crypt curl dga div x4linux doc dri dvd dvdr dvdread emboss encode esd fam foomaticdb fortran gcj gd gdbm gif gimpprint glx gphoto2 gpm gpr400 gtk gtk2 gtkhtml imagemagick imap iml ib insecure-drivers ipv6 java jikes jpeg kerberos libg++ libwww live lufsusermou nt lzo mad mbox mjpeg mldonkeypango mmx motif mozilla mozsvg mp3 mpeg ncurses ne twork nls nvidia ogg oggvorbis opengl oss pam pcmcia pcsc-lite pdflib perl png p ython quicktime readline real rtc scanner sdl silc spell sse sse2 ssl svga tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts unicode usb v4l vidix vorbi s wmf x86 xanim xface xfs xml2 xmms xv xvid zlib linguas_zh_CN linguas_zh_TW lin guas_ja linguas_ko" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS
same here on two computers, nothing i can do about changing nvidia to nv in xorg.conf :(
Jochen and Patrick: could you post the output of startx or the log in /var/log/Xorg.0.log please? And would you read http://bugs.gentoo.org/show_bug.cgi?id=89080 please? Looks like we are all suffering from the same problem...
Sorry for that double-posting... I forgot: *MAYBE* this is a duplicate of bug 89080
Updated 3 other nvidia machines to 2.3.5 now and all the same problem. Maybe the other bug is related somehow, yet i wouldn't say it's identical. For now, adding >=sys-libs/glibc-2.3.5 to the /etc/portage/package.mask and emerge -u world, nvidia-kernel and nvidia-glx seems to be the only fix for the problem.
I can confirm that downgrading/reverting to glibc-2.3.4.20050125-r1 solved the problem for me too. I did not have to re-emerge xorg-x11, nvidia-kernel or nvidia-glx. glibc-2.3.5 IS the reason for those troubles.
Forget about the "duplicate of bug 89080" in my comment #3. The reporter of bug 89080 still using glibc-2.3.4.20050125-r1 and he did no update to glibc-2.3.5.
Created attachment 57004 [details] ouput of startx attached is the output of startx -- -layout opengl (this selects the nv driver in my xorg.conf) and the Xorg.0.log. here and excerpt from strace: [pid 14070] write(0, "(II) Initializing built-in exten"..., 43) = 43 [pid 14070] write(0, "(II) Initializing built-in exten"..., 47) = 47 [pid 14070] write(0, "(II) Initializing built-in exten"..., 44) = 44 [pid 14070] write(0, "(II) Initializing built-in exten"..., 43) = 43 [pid 14070] write(0, "(II) Initializing extension GLX\n", 32) = 32 [pid 14070] modify_ldt(17, {entry_number:0, base_addr:0x8454388, limit:512, seg_ 32bit:1, contents:0, read_exec_only:0, limit_in_pages:0, seg_not_present:0, usea ble:1}, 16) = 0 [pid 14070] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
Created attachment 57005 [details] Xorg.0.log
Created attachment 57012 [details] backtrace of segfault that's the backtrace I get from X's core
Jochen: thanks for your effort. Seems to be the same problem that I had (look at bug 89080). Downgrading/reverting to glibc-2.3.4.20050125-r1 solved the problem for me. Please try it if you haven't done already ;-) Any suggestions what to do with the glibc-nvidia problem?
This might just be normal binary breakage expected from changing Glibc versions. Since the driver seems to compile/link fine, the proprietary code is probably at fault and thus there's not much you guys can do until nVidia releases a new one.
Even though it doesn't crash for me, I'm also experiencing problems with nvidia-glx and glibc-2.3.5 (on an nptl-only system). My log says: dlopen: /usr/lib/modules/extensions/libGLcore.so: undefined symbol: __glXLastContext (EE) Failed to load /usr/lib/modules/extensions/libGLcore.so (EE) Failed to load module "GLcore" (loader failed, 7) Inconsistency detected by ld.so: ../sysdeps/generic/dl-tls.c: 75: _dl_next_tls_modid: Assertion `result <= _rtld_local._dl_tls_max_dtv_idx' failed! Just opengl-update xorg-x11 at least let's me start up my system again until some updated nvidia-glx will be out...
Jochen: I know what you mean by "normal breakage", so please don't take that personally: I do NOT think that broken nvidia-drivers are normal. A broken X Window System is a serious problem. I wonder if the testers of glibc-2.3.5 had no nvidia cards... I can't imagine that they did not have ANY problems with the new glibc. Strange. What about masking glibc-2.3.5 until this bug is resolved? Would that be a possible temporary solution? Olaf: could you take a look on bug 73076 please? Maybe this bug is similar to your problem.
Just searched on the forum and I found this thread: http://forums.gentoo.org/viewtopic-t-327623.html It tells, that using the ORIGINAL installer of the nvidia-drivers makes them working with glibc-2.3.5. Can someone confirm that? Searched the nvidia-forum, but I didn't find anything about glibc-2.3.5 & nvidia problems.
Thought I'd see whether toolchain has ideas besides comment #11.
I can confirm that using the ORIGINAL installer got me a perfectly working setup with glibc 2.3.5 and nvidia-glx-1.07171...
sorry for double posting.. it was a typo, I ment 1.0.7174
Using the NVIDIA installer of driver 7174 fixed GLX with glibc-2.3.5 for me too.
Using the ORIGINAL nvidia-installer fixes the problem nvidia-glx & glibc-2.3.5 for me too. But why?????? Why does the nvidia-installer works, and the gentoo-install does NOT work? As the title for this bug has been changed one should notice that glibc-2.3.5 breaks ALL versions of nvidia-drivers (see http://bugs.gentoo.org/show_bug.cgi?id=89080#c12), when not using the original nvidia-installer. To be *perfecty* correct, the version number of nvidia-glx should be removed.
Seems clear it's non-toolchain, then.
may i suggest to compare the result of the original nvidia installer (in terms of installed files etc) with the results of the gentoo installer?
Re comment #13 I use only nvidia cards, and I haven't hit this problem. If I had, I wouldn't have unmasked glibc. There should be NO difference between what the nvidia-installer and the nvidia-glx package install, so can you please try emerging nvidia-glx after you have your working system from nvidia-installer?
Not quite true, there are some differences. * Applying NVIDIA_glx-1.0.6629-makefile.patch ... [ ok ] * Applying NVIDIA_glx-1.0.6629-defines.patch ... [ ok ] * Applying NVIDIA_glx-1.0.6629-glheader.patch ... [ ok ] I'll check these patches and try some overlay nvidia ebuilds. If the normal installer works, the only possibilities are either the configuration through the ebuild (unlikely) or the patches. Guess I'll have the answer in about a hour.
OK, did the following: - emerged glibc 2.3.5 - startx didnt worked anymore - remerged nvidia-kernel and nvidia-glx - still didnt worked - used the nvidia installer - X worked - remerged nvidia-kernel to make sure the gentoo module is beeing used - still worked - some switching between xorg-x11 and nvidia in opengl-update - still worked - emerge -C nvidia-glx - X doesn't work anymore (as intendet) - emerge nvidia-glx - X worked So whatever the nvidia installer did, it fixed the problem.
I can confirm this, too. After using the nvidia installer I can emerge nvidia-glx without my system getting broken again... So someone should take a closer look what files the nvidia installer alters/creates... There must be at least one file that the nvidia installer touches, but the ebuild doesn't... Or could it be about hardcoded pathes in some of the binary files?
Re the glx patches, those are trivial... Did youu 'rmmod nvidia && modprobe nvidia' after re-emerging nvidia-kernel? Could youu please provide emerge --info, a log of the nvidia-installer install, and a log of 'emerge -v nvidia-kernel nvidia-glx'?
Created attachment 57202 [details] nvidia-installer log
Same problem here with gentoo-install. Installing with nvidia-installer is ok. gollum log # emerge --info Portage 2.0.51.20-r4 (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.3.5-r0, 2.6.11-gentoo-r6 i686) ================================================================= System uname: 2.6.11-gentoo-r6 i686 AMD Athlon(TM) XP 3000+ Gentoo Base System version 1.6.11 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.4 [enabled] dev-lang/python: 2.3.5 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r8 sys-devel/libtool: 1.5.14 virtual/os-headers: 2.6.11 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -fomit-frame-pointer -march=athlon-xp" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /usr/kde/share /etc/env.d" CXXFLAGS="-O2 -fomit-frame-pointer -march=athlon-xp" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distcc distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://mirror.switch.ch/mirror/gentoo/ ftp://mirror.nutsmaas.nl/gentoo/ http://gentoo.inode.at/ ftp://mir.zyrianes.net/gentoo/" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/local/build/tmp/portage" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowext X aalib alsa apm arts audiofile avi berkdb bitmap-fonts cdparanoia cdr crypt cups curl dvd emboss encode esd fam flac foomaticdb fortran gdbm gif gnome gpm gstreamer gtk gtk2 imagemagick imlib ipv6 java jpeg kde libg++ libwww mad mikmod mmx motif mozilla mp3 mpeg ncurses nls ogg oggvorbis opengl oss pam pdflib perl png python qt quicktime readline samba sdl slang speex spell sse ssl svga tcpd theora tiff truetype truetype-fonts type1-fonts vorbis xml2 xmms xv zlib" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
Oh well, now I'm a bit puzzeld... now with the emerge installation I don't have any problem. Hm, maybe the forced update with the nvidia-installer cleaned up something? In any case I'm attaching the emerge -v nvidia-kernel nvidia-glx logfile.
Created attachment 57208 [details] emerge -v nvidia-kernel nvidia-glx
Here the description of what I've done: 1. after emerging glibc 2.3.5 I couldn't start X anymore 2. emerge nvidia-kernel nvidia-glx and reboots This step didn't solve the problem 3. nvidia-installer --force-update After this step X started ok 4. emerge -v nvidia-kernel nvidia-glx Now even after reinstalling with the ebuild, I CAN start X Someone else has seen the same behaviour?
Thanks for your efforts, edmondo!! I also did some testing, and I found out the following: emerge glibc-2.3.5 nvidia-glx --> X does not start using the nvidia-installer --> X starts rm -rf /usr/lib/opengl/nvidia --> X starts (the GLX module is loaded) emerge -C nvidia-glx --> X does not start emerge nvidia-glx --> X starts (I did NOT use the nvidia-installer!) rm -rf /usr/lib/opengl/nvidia /usr/lib/modules/drivers/nvidia* --> X does not start emerge nvidia-glx --> X starts (without using nvidia-installer) I am totally confused about that...
OK, now I tested 3 times with rebooting: after an "rm -rf /usr/lib/opengl/nvidia" X does start and it loads the nvidia-driver AND the glx extension. Very strange. "opengl-update nvidia" does not work, it gives an error message, that the profile nvidia could not be found. That should be the way it is. But X starts without any problems!!!!!!!!!!!!!!!!!! When deleting /usr/lib/modules/drivers/nvidia* X does NOT start. But an "emerge nvidia-glx" lets X start again.
Bingo. Seems like I have located the lib causing all these pains. I first thought it might be the libGL* libraries, since the nvidia installer creates them in /usr/lib while the ebuild is using /usr/lib/opengl/nvidia/lib. However, a lsof told me different, the GL libs are getting loaded from the right location. However, one lib is not: Eternal lib # lsof | grep libnvidia-tls X 8495 root mem REG 22,7 2004 1925818 /usr/lib/tls/libnvidia-tls.so.1.0.7174 That made me curious. The tls.so in /usr/lib/tls was of an older date then the libs installed with nvidia-glx, the date matches the libs installed with the original installer. One rm -rf /usr/lib/tls && ldconfig && startx later: Bingo, it is crashing like before. I reinstalled the original nvidia files and compared them: /usr/lib/tls: -rwxr-xr-x 1 root root 2004 Apr 25 22:56 libnvidia-tls.so.1.0.7174* /usr/lib/opengl/nvidia/lib: -rwxr-xr-x 1 root root 2320 Apr 25 22:59 libnvidia-tls.so.1.0.7174* Eternal lib # diff /usr/lib/tls/libnvidia-tls.so.1.0.7174 /usr/lib/opengl/nvidia /lib/libnvidia-tls.so.1.0.7174 Files /usr/lib/tls/libnvidia-tls.so.1.0.7174 and /usr/lib/opengl/nvidia/lib/libnvidia-tls.so.1.0.7174 differ So we have found the problem. Only question left is why and what to do about it.
There are two different libnvidia-tls.so libraries installed in /usr/lib/opengl/nvidia/tls (2004 byte) /usr/lib/opengl/nvidia/lib (2320 byte) As for standard linuxthreads compiled glibc 2.3.5, the one in nvidia/tls is the right one, the other will crash. Maybe it is different for NTPL enabled systems and that might be a clue why it works for Jeremy but no one other here. Now all we need is a small change in the opengl-update script. In Line 201 if getconf GNU_LIBPTHREAD_VERSION | grep -qi nptl; then Either comment that whole line out, together with the fi closing it or make a second condition for glibc >= 2.3.5. Whoever wants to make a updated opengl-update and a ebuild, go ahead, it is too late for me to use awk ;) Also, there is a major bug in the opengl-update script in line 229 if [[ -e "${PREFIX}/${LIBDIR}/${LIBDIR}/opengl/${GL_LOCAL}/lib/tls" ]]; then there is one LIBDIR too much, of course it should be if [[ -e "${PREFIX}/${LIBDIR}/opengl/${GL_LOCAL}/lib/tls" ]]; then After these changes, everything will work smoothly.
The problem is some systems which are nptlonly need the tls/libnvidia-tls.so copied in /usr/lib, and nptl -nptlonly systems need it in /usr/lib/tls grumble grumble grumble... I think this might best be solved by checking how glibc was built (nptl/nptlonly) in nvididia-glx and having opengl-update be more dumb about handling it (ie, relying on the nvidia-glx ebuild to put it in the right place). I'll get an ebuild/opengl-update here for you to test in a jiff
please package.unmask and test opengl-update-2.2.0 and nvidia-glx-1.0.7174-r2 when you get them off rsync.
If this helps: amd64 ~ # ls -l /usr/lib64/opengl/nvidia/lib -rwxr-xr-x 1 root root 2984 Apr 25 21:05 libnvidia-tls.so.1.0.7174 amd64 ~ # ls -l /usr/lib64/opengl/nvidia/tls/ -rwxr-xr-x 1 root root 3024 Apr 25 21:05 libnvidia-tls.so.1.0.7174
baz: I'm not sure what you mean by that... please test the new ebuilds and let me know if that helps
The fix of opengl-update + nvidia-glx appears to work for me.
Does NOT work for me on AMD64, I noticed that the emerge 'hangs' for ages on: >>> Install nvidia-glx-1.0.7174-r2 into /var/tmp/portage/nvidia-glx-1.0.7174-r2/image/ category media-video then completes without error Error message on 'startx' is identical to previously, ie; Fatal server error: Caught signal 11. Server aborting
It doesn't work for me too. Additional problem with my system is that NVidia-installer fails to install drivers too.
nvidia-installer doesn't work for me either, I get errors creating simlinks, presumably because they were already there.
Ok, what happens if you try disabling glx in xorg.conf? Also, regarding comment #35, the double libdirs bug was fixed in February... I think in 2.1.1. Baz, pleasse attach your Xorg.0.log and output of startx. Ark, please provide the output of 'emerge -v nvidia-glx nvidia-kernel && rmmod nvidia && modprobe nvidia && startx' as well as the Xorg.0.log
the nvidia installer seems to alter the following files: # equery k nvidia-glx [ Checking media-video/nvidia-glx-1.0.7174-r2 ] !!! /usr/lib/opengl/nvidia/tls-nptl/libnvidia-tls.so.1.0.7174 does not exist !!! /usr/lib/opengl/nvidia/lib/libGLcore.so.1 does not exist !!! /usr/lib/opengl/nvidia/lib/libnvidia-tls.so.1 does not exist !!! /usr/lib/opengl/nvidia/lib/libGLcore.so does not exist !!! /usr/lib/opengl/nvidia/tls-lt/libnvidia-tls.so.1 does not exist !!! /usr/lib/opengl/nvidia/tls-lt/libnvidia-tls.so does not exist !!! /usr/lib/opengl/nvidia/extensions/libglx.so does not exist !!! /usr/lib/libXvMCNVIDIA.so.1.0.7174 has wrong mtime (is 1114536455, should be 1114504107) !!! /usr/lib/opengl/nvidia/tls-lt/libnvidia-tls.so.1.0.7174 does not exist !!! /usr/lib/opengl/nvidia/tls-nptl/libnvidia-tls.so.1 does not exist !!! /usr/lib/opengl/nvidia/lib/libnvidia-tls.so.1.0.7174 does not exist !!! /usr/lib/opengl/nvidia/lib/libGL.so.1.0.7174 does not exist !!! /usr/lib/opengl/nvidia/lib/libnvidia-tls.so does not exist !!! /usr/lib/opengl/nvidia/lib/libGL.so.1 does not exist !!! /usr/lib/libXvMCNVIDIA.a has wrong mtime (is 1114536455, should be 1114504107) !!! /usr/lib/opengl/nvidia/lib/libGL.so does not exist !!! /usr/lib/modules/drivers/nvidia_drv.o has wrong mtime (is 1114536455, should be 1114504107) !!! /usr/lib/opengl/nvidia/lib/libGLcore.so.1.0.7174 does not exist !!! /usr/lib/opengl/nvidia/lib/libGL.la does not exist !!! /usr/lib/modules/drivers/nvidia_drv.so has wrong mtime (is 1114536455, should be 1114504107) !!! /usr/bin/nvidia-bug-report.sh has wrong mtime (is 1114536455, should be 1114504107) !!! /usr/lib/opengl/nvidia/tls-nptl/libnvidia-tls.so does not exist * 22 out of 44 files good
Created attachment 57304 [details] Arkadiusz Kolacz: emerge -v nvidia-glx This is output of emerge -v nvidia-glx, see comment 42 and 44
Created attachment 57305 [details] emerge -v nvidia-kernel see comment 42 and 44
Created attachment 57306 [details] Xorg.0.log see comment 42 and 44
I've attached files with output of emerge nvidia-glx and nvidia-kernel. I can't see anything special in that files. In Xorg.0.log you can see, that xorg crashes after starting GLX. rmmod nvidia and modprobe nvidia doesn't produce any output. BTW: Short version of my name is Arek ;)
I tested the new nvidia-glx and the new opengl-update, but it does NOT work!! What I did: exit X /etc/init.d/xdm stop rmmod nvidia emerge -C nvidia-glx nvidia-kernel uninstall nvidia-drivers using nvidia-installer rm -rf /usr/lib/opengl/nvidia rm -rf /usr/lib/modules/drivers/nvidia* emerge opengl-update nvidia-glx nvidia-kernel modprobe nvidia /etc/init.d/xdm start Starting X produces exactly the same error message as in comment #48 (and I posted it also on http://bugs.gentoo.org/show_bug.cgi?id=89080#c5). emerging nvidia-glx gives me the same messages as in comment 46, except that I'm using an i686 machine, so the drivers are not installed in /usr/lib64. btw. Arek: why is nvidia-glx installed into /usr/lib/32 AND into /usr/lib64???? And a question to the maintainer: this bug has priority set to normal. Bug 89080 describes a similar problem (X does not start) and this bug is set to critical. So why is "our" bug only normal?? ;-)
Sorry for my typo in comment 50: it should be: btw. Arek: why is nvidia-glx installed into /usr/lib32 AND into /usr/lib64???? Jeremy: disabling the "Load glx" line in xorg.conf let's X start fine (see http://bugs.gentoo.org/show_bug.cgi?id=89080#c8)
Juergen: I don't know for sure ;). I thing that on amd64 there are installed 64-bit and 32-bit versions of OpenGL. 32-bit version is used when I run 32 bit applications... When I try to install drivers from nvidia-installer, installer always asks me if I want to instal additional 32-bit version of driver for running 32-bit applications. My answer was always "yes"... Is it normal that librarys are installed in both directores? (I thing yes, but I'm not sure) BTW: There is a easy way to start X. Type as root: "opengl-update xorg-x11"
Arek: you know more about 64bit systems than me... because I know NOTHING about that. But I wondered why there are two versions of the nvidia-driver... Please correct me if I'm wrong: When you use opengl-update xorg-x11 you "overrun" the nvidia-drivers and the xorg-drivers are being used instead of the nvidia ones. That's why X can be started (http://bugs.gentoo.org/show_bug.cgi?id=89080#c17). But we ALL want to use the nvidia-drivers, don't we??? ;-)
Arek, thanks, but you're using the old nvidia-glx ebuild rather than the new one I hope fixes the bug. Please add the following to /etc/portage/package.unmask: =x11-base/opengl-update-2.2.0 =media-video/nvidia-glx-1.0.7174-r2 Then emerge nvidia-glx. That should solve the problem. Juergen: What version of nvidia-glx are you using? 32bit libs are installed in /usr/lib32 and 64bit libs are installed in /usr/lib64 on amd64. Also, I ignore the 'severity' indicator on bugs, so that's why it's set to normal. The fact that I'm responding and pushing out ebuilds to test fixes for this bug should indicate that it is a high priority for me, not some silly dropbox ;)
Thanks for the information Jeremy... one MUST know that ;-) I'm using the new ebuild, which does NOT work for me. emerge -pv vidia-glx [ebuild R ] media-video/nvidia-glx-1.0.7174-r2
Juergen: You are right, but haveing working X, even if nvidia drivers doesn't work, is very useful ;)
New ebuild (nvidia-glx-1.0.7174-r2) does NOT work for me neither.
Quote: Baz, pleasse attach your and output of startx. amd64 ~ # startx X Window System Version 6.8.2 Release Date: 9 February 2005 X Protocol Version 11, Revision 0, Release 6.8.2 Build Operating System: Linux 2.6.11-gentoo-r2 x86_64 [ELF] Current Operating System: Linux baz1 2.6.11-gentoo-r6 #2 Sat Apr 23 13:06:19 BST 2005 x86_64 Build Date: 21 March 2005 Before reporting problems, check http://wiki.X.Org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Tue Apr 26 20:36:56 2005 (==) Using config file: "/etc/X11/xorg.conf" Using vt 8 *** If unresolved symbols were reported above, they might not *** be the reason for the server aborting. Fatal server error: Caught signal 11. Server aborting Please consult the The X.Org Foundation support at http://wiki.X.Org for help. Please also check the log file at "/var/log/Xorg.0.log" for additional information. XIO: fatal IO error 104 (Connection reset by peer) on X server ":0.0" after 0 requests (0 known processed) with 0 events remaining. Xorg.0.log is identic
I too suggest this bug is at least critical, not normal.
Ok, I'm guessing that since it does fix problems for some and doesn't for others that we've got 2 separate problems here. For those still with problems AFTER trying the -r2 ebuild, please provide the following info: 1) Does X start if you remove 'Load "glx"' from /etc/X/xorg.conf? 2) ldd /usr/lib/modules/extensions/libglx.so 3) ls -l <the libnvidia-tls.so file listed in #2> 4) /lib/libc.so.6 | grep hrea 5) /lib/tls/libc.so.6 | grep hrea If you don't have one of those files, please say so. Note that you should be using 'opengl-update nvidia' with with opengl-update-2.2.0 and nvidia-glx-1.0.7174-r2 here, thanks.
Marking critical to appease people even though it doesn't matter
My answer on 2), 4), 5): smeagol lib # opengl-update nvidia * Switching to nvidia OpenGL interface ... >>> Regenerating /etc/ld.so.cache... * Caching service dependencies ... [ ok ] smeagol lib # ldd /usr/lib/modules/extensions/libglx.so libGLcore.so.1 => /usr/lib/opengl/nvidia/lib/libGLcore.so.1 (0x00002aaaaacc0000) libnvidia-tls.so.1 => /usr/lib/opengl/nvidia/lib/libnvidia-tls.so.1 (0x00002aaaab4a5000) smeagol lib # /lib/libc.so.6 | grep hrea linuxthreads-0.10 by Xavier Leroy libthread_db work sponsored by Alpha Processor Inc Thread-local storage support included. smeagol lib # /lib/tls/libc.so.6 | grep hrea bash: /lib/tls/libc.so.6: No such file or directory 3) - is not clear for me... ;) 1) - I will check in few minut. Note: I'm now under KDE started with opengl-update x11-xorg, I just opened terminal, and entered, what you see, then make copy & paste. Is it good?
I just did the steps I described in comment 50. 1) Does X start if you remove 'Load "glx"' from /etc/X/xorg.conf? Yes, it does. 2) ldd /usr/lib/modules/extensions/libglx.so ldd /usr/lib/modules/extensions/libglx.so linux-gate.so.1 => (0xffffe000) libGLcore.so.1 => /usr/lib/opengl/nvidia/lib/libGLcore.so.1 (0xb77f6000) libnvidia-tls.so.1 => /usr/lib/opengl/nvidia/lib/libnvidia-tls.so.1 (0xb77f4000) 3) ls -l <the libnvidia-tls.so file listed in #2> ls -l /usr/lib/opengl/nvidia/lib/libnvidia-tls.so* lrwxrwxrwx 1 root root 26 26. Apr 22:14 /usr/lib/opengl/nvidia/lib/libnvidia-tls.so -> ../tls-lt/libnvidia-tls.so lrwxrwxrwx 1 root root 28 26. Apr 22:14 /usr/lib/opengl/nvidia/lib/libnvidia-tls.so.1 -> ../tls-lt/libnvidia-tls.so.1 lrwxrwxrwx 1 root root 35 26. Apr 22:14 /usr/lib/opengl/nvidia/lib/libnvidia-tls.so.1.0.7174 -> ../tls-lt/libnvidia-tls.so.1.0.7174 4) /lib/libc.so.6 | grep hrea /lib/libc.so.6 | grep hrea linuxthreads-0.10 by Xavier Leroy libthread_db work sponsored by Alpha Processor Inc Thread-local storage support included. 5) /lib/tls/libc.so.6 | grep hrea /lib/tls/libc.so.6 | grep hrea bash: /lib/tls/libc.so.6: Datei oder Verzeichnis nicht gefunden (which means: file or directory not found)
3) lrwxrwxrwx 1 root root 25 Apr 26 20:09 /usr/lib/opengl/nvidia/lib/libnvidia-tls.so -> libnvidia-tls.so.1.0.7174 lrwxrwxrwx 1 root root 25 Apr 26 20:09 /usr/lib/opengl/nvidia/lib/libnvidia-tls.so.1 -> libnvidia-tls.so.1.0.7174 -rwxr-xr-x 1 root root 2984 Apr 26 20:09 /usr/lib/opengl/nvidia/lib/libnvidia-tls.so.1.0.7174
1) Does X start if you remove 'Load "glx"' from /etc/X/xorg.conf? Yes 2) ldd /usr/lib/modules/extensions/libglx.so libGLcore.so.1 => /usr/lib/opengl/nvidia/lib/libGLcore.so.1 (0x00002aaaaacc6000) libnvidia-tls.so.1 => /usr/lib/opengl/nvidia/lib/libnvidia-tls.so.1 (0x00002aaaab4ab000) 3) ls -l <the libnvidia-tls.so file listed in #2> lrwxrwxrwx 1 root root 28 Apr 26 09:07 /usr/lib/opengl/nvidia/lib/libnvidia-tls.so.1 -> ../tls-lt/libnvidia-tls.so.1 4) /lib/libc.so.6 | grep hrea linuxthreads-0.10 by Xavier Leroy libthread_db work sponsored by Alpha Processor Inc Thread-local storage support included. 5) /lib/tls/libc.so.6 | grep hrea -bash: /lib/tls/libc.so.6: No such file or directory
after a rsync and re-emerge-ing (!!!) nvidia-kernel-1.0.7174 / nvidia-glx-1.0.7174-r2 it seems to work... thanks!
even though I haven been asked... I'm one of the happy guys for whom the nvidia installer fixed things... and as a difference to the previous posters I see: aaron@therion ~ $ /lib/tls/libc.so.6 | grep hrea Native POSIX Threads Library by Ulrich Drepper et al Thread-local storage support included.
Arek: By your answer to #3, it doesn't look like you're using the -r2 ebuild. Baz, Juergen: ok, those libs are correct for linuxthreads, so my guess is there's a problem specific to linuxthreads. Can you provide me with 'emerge --info' and also verify that nothing's change in it since you emerged glibc-2.3.5
Olaf: can you please try the new opengl-update and nvidia-glx ebuilds? Dick: What are the state of your nptl and nptlonly use flags?
*** Bug 90390 has been marked as a duplicate of this bug. ***
Jeremy: this is my emerge --info as you requested. emerge --info Portage 2.0.51.20-r5 (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.3.5-r0, 2.6.11-nitro2 i686) ================================================================= System uname: 2.6.11-nitro2 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz Gentoo Base System version 1.6.11 ccache version 2.4 [enabled] dev-lang/python: 2.3.5 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.97 sys-devel/libtool: 1.5.14 virtual/os-headers: 2.6.11 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -mtune=pentium4 -O3 -pipe -mmmx -msse -msse2 -ffast-math -mfpmath=sse -fforce-addr -falign-functions=4 -fprefetch-loop-arrays -funroll-loops" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -mtune=pentium4 -O3 -pipe -mmmx -msse -msse2 -ffast-math -mfpmath=sse -fforce-addr -falign-functions=4 -fprefetch-loop-arrays -funroll-loops" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://gentoo.inode.at/source/ http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" LANG="de_DE@euro" LC_ALL="de_DE@euro" LINGUAS="de" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/overlays/gentoo-de /usr/local/overlays/bmg-main" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 X aalib acpi alsa apm arts avi berkdb bitmap-fonts cdr crypt cups curl directfb divx4linux dvd dvdr emboss encode esd fam flac foomaticdb fortran gdbm gif gpm gtk gtk2 imagemagick imlib ipv6 jabber java joystick jpeg kde libg++ libwww mad mikmod mmx mmx2 motif mp3 mpeg ncurses nls nvidia ogg oggvorbis opengl oss pam pdflib perl png ppds python qt quicktime readline real scanner sdl slang speex spell sse sse2 ssl svga tcpd tiff truetype truetype-fonts type1-fonts usb videos vorbis wmf wxwindows xml2 xmms xv zlib linguas_de" Unset: ASFLAGS, CTARGET, LDFLAGS I did not change anything of the glibc-2.3.5 installation since I used the nvidia-installer for my nvidia-drivers (before that I had to use glibc-2.3.4.20050125-r1)
OKi, I had -r1 (Is it posible, that r1 was installed on -r2 after emerge --sync && emerge -u world ?) Now, I have results like Juergen, GLX doesn't work.
amd64 ~ # emerge --info Portage 2.0.51.20-r4 (default-linux/amd64/2005.0, gcc-3.4.3-20050110, glibc-2.3.5-r0, 2.6.11-gentoo-r6 x86_64) ================================================================= System uname: 2.6.11-gentoo-r6 x86_64 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System version 1.6.11 dev-lang/python: 2.3.5 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r8 sys-devel/libtool: 1.5.14 virtual/os-headers: 2.6.11 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3 /share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon64 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox strict" GENTOO_MIRRORS="http://gentoo.blueyonder.co.uk http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo/" LANG="en_GB.UTF-8" LC_ALL="en_GB.UTF-8" LINGUAS="en_GB" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/fluidportage/trunk" SYNC="rsync://rsync.uk.gentoo.org/gentoo-portage" USE="amd64 X a52 aac aalib acpi alsa apache2 audiofile avi bash-completion berkdb bitmap-fonts bonobo cdr crypt cups cur l devmap directfb dts dv dvb dvd dvdr dvdread emul-linux-x86 encode esd fam fbcon ffmpeg flac font-server foomaticdb for tran gd gif glut gnome gphoto2 gpm gstreamer gtk gtk2 icq imagemagick imlib ipv6 jack java javascript jp2 jpeg kde libww w lzw lzw-tiff mad matroska mikmod mime mjpeg motif mp3 mpeg mysql mythtv nas ncurses nls nvidia offensive ogg oggvorbis opengl oss pam pda perl php ping png python qt quicktime readline real samba sdl spl ssl tcltk tcpd theora tiff truetyp e truetype-fonts type1-fonts unicode usb userlocales v4l v4l2 vcd vcl videos vorbis xanim xine xinerama xml xml2 xmlxpri nt xmms xmmx xpm xrandr xv xvid xvmc zlib linguas_en_GB" Unset: ASFLAGS, CTARGET, LDFLAGS
Baz, you've pretty much go the same configuration as I do, but I use nptl. When I forced linuxthreads (via 'LD_ASSUME_KERNEL=2.4.1 startx'), X still ran for me, so I'm not sure what's going on here. Can you try recompiling glibc with USE=nptl? You'll need to re-emerge nvidia-glx after that as well. If that works, can you then try starting X with 'LD_ASSUME_KERNEL=2.4.1 startx'? Juergen, could you please try the above also, but also lighten up on the CFLAGS until we get this debugged... I'd suggest '-march=pentium3 -O2 -pipe' for now, thanks.
1) Does X start if you remove 'Load "glx"' from /etc/X/xorg.conf? YES 2) ldd /usr/lib/modules/extensions/libglx.so linux-gate.so.1 => (0xffffe000) libGLcore.so.1 => /usr/lib/opengl/nvidia/lib/libGLcore.so.1 (0xb77ed000) libnvidia-tls.so.1 => /usr/lib/opengl/nvidia/lib/libnvidia-tls.so.1 (0xb77eb000) 3) ls -l <the libnvidia-tls.so file listed in #2> ls -l /usr/lib/opengl/nvidia/lib/libnvidia-tls.so.1 lrwxrwxrwx 1 root root 28 Apr 26 21:24 /usr/lib/opengl/nvidia/lib/libnvidia-tls.so.1 -> ../tls-lt/libnvidia-tls.so.1 4) /lib/libc.so.6 | grep hrea linuxthreads-0.10 by Xavier Leroy libthread_db work sponsored by Alpha Processor Inc 5) /lib/tls/libc.so.6 | grep hrea /lib/tls/libc.so.6: No such file or directory $ emerge --info Portage 2.0.51.20-r5 (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.3.5-r0, 2.6.11-gentoo-r6 i686) ================================================================= System uname: 2.6.11-gentoo-r6 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz Gentoo Base System version 1.6.11 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.5 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r8 sys-devel/libtool: 1.5.14 virtual/os-headers: 2.6.11 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks sfperms strict" GENTOO_MIRRORS="http://mirror.switch.ch/mirror/gentoo/ ftp://ftp.solnet.ch/mirror/Gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.ch.gentoo.org/gentoo-portage" USE="x86 X Xaw3d a52 aac aalib acpi acpi4linux alsa arts audiofile avi bash-completion berkdb bidi bitmap-fonts bmp bzlib cddb cdparanoia cdr crypt cups curl dga dio divx4linux dts dv dvd dvdr dvdread emacs emboss encode esd evo evo2 exif faac faad fam fame fbcon ffmpeg flac foomaticdb fortran freetype ftp gb gcj gd gdbm ggi gif gmail gnome gpm gstreamer gtk gtk2 hal httpd icq ieee1394 imagemagick imap imlib jabber java jpeg kdeenablefinal kdexdeltas latex lcms libcaca libg++ libwww lirc lzo mad matroska mikmod mime mjpeg mmx mmx2 motif mozilla moznocompose moznoirc moznomail mozsvg mp3 mpeg msn nas ncurses neXt nls nvidia ogg oggvorbis opengl oss pam pda pdflib perl pic png ppds python qt quicktime readline real samba scanner sdl slang snmp spell sse sse2 ssl svg svga tcltk tcpd tetex theora tiff truetype truetype-fonts type1-fonts usb v4l v4l2 vcd visualization vlm vorbis win32codecs wmf xanim xine xml xml2 xosd xprint xv xvid xvmc zlib video_cards_nvidia" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS $ emerge glibc -pv sys-libs/glibc-2.3.5 -build -debug -erandom -hardened (-multilib) +nls -nomalloccheck -nptl -nptlonly +pic -userlocales I did not change anything after emerging glibc-2.3.5, and I never installed the drivers using the nvidia-installer...
Baz ................... Can you try recompiling glibc with USE=nptl? emerging now
I recompiled glibc-2.3.5 with USE=nptl, but GLX still doesn't work.
Samuel, did you re-emerge nvidia-glx after glibc? Can you reanswer those 5 questions again with the nptl glibc?
1) ok... I remerged glibc with ntplonly (as I initially had before playing around), unmasked the requested versions of opengl-update and nvidia-glx, emerged then - did opengl-update nvidia-glx... And my X still works fine with glx module loaded... 2) aaron@therion /lib $ ldd /usr/lib/modules/extensions/libglx.so linux-gate.so.1 => (0xffffe000) libGLcore.so.1 => /usr/lib/opengl/nvidia/lib/libGLcore.so.1 (0xb77f7000) libnvidia-tls.so.1 => /usr/lib/opengl/nvidia/lib/libnvidia-tls.so.1 (0xb77f4000) 3) aaron@therion /lib $ ls -l /usr/lib/opengl/nvidia/lib/libnvidia-tls.so.1 lrwxrwxrwx 1 root root 30 Apr 27 07:11 /usr/lib/opengl/nvidia/lib/libnvidia-tls.so.1 -> ../tls-nptl/libnvidia-tls.so.1 4) aaron@therion /lib $ /lib/libc.so.6 | grep hrea Native POSIX Threads Library by Ulrich Drepper et al Thread-local storage support included. 5) aaron@therion /lib $ /lib/tls/libc.so.6 | grep hrea bash: /lib/tls/libc.so.6: No such file or directory
Jeremy, yes I re-emergef nvidia-glx after glibc with USE=nptl. I have the same asnwer with USE="-nptl" and USE="nptl": 1) Does X start if you remove 'Load "glx"' from /etc/X/xorg.conf? YES 2) ldd /usr/lib/modules/extensions/libglx.so linux-gate.so.1 => (0xffffe000) libGLcore.so.1 => /usr/lib/opengl/nvidia/lib/libGLcore.so.1 (0xb77ed000) libnvidia-tls.so.1 => /usr/lib/opengl/nvidia/lib/libnvidia-tls.so.1 (0xb77eb000) 3) ls -l <the libnvidia-tls.so file listed in #2> ls -l /usr/lib/opengl/nvidia/lib/libnvidia-tls.so.1 lrwxrwxrwx 1 root root 28 Apr 26 21:24 /usr/lib/opengl/nvidia/lib/libnvidia-tls.so.1 -> ../tls-lt/libnvidia-tls.so.1 4) /lib/libc.so.6 | grep hrea linuxthreads-0.10 by Xavier Leroy libthread_db work sponsored by Alpha Processor Inc Thread-local storage support included. 5) /lib/tls/libc.so.6 | grep hrea /lib/tls/libc.so.6: No such file or directory Re-emerging glibc with ntponly....
Jeremy Huddleston, as gentoo default, -nptl -nptlonly # emerge info Portage 2.0.51.20-r5 (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.3.5-r0, 2.6.11.7-dm0 i686) ================================================================= System uname: 2.6.11.7-dm0 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz Gentoo Base System version 1.6.11 dev-lang/python: 2.3.5 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r8 sys-devel/libtool: 1.5.14 virtual/os-headers: 2.6.11 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O3 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-O2 -mcpu=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://ftp.snt.utwente.nl/pub/os/linux/gentoo/ http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" LC_ALL="nl_NL@euro" LINGUAS="nl" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage-overlay" SYNC="rsync://routi.marinus/gentoo-portage" USE="x86 X aalib alsa apm arts avi bash-completion berkdb bitmap-fonts bluetooth cdparanoia crypt cscope cups curl directfb dvd emboss encode fam flac foomaticdb fortran gd gdbm gif gstreamer gtk gtk2 guile imagemagick imlib ipv6 java jpeg junit kde kdeenablefinal ldap libg++ libwww mad mikmod mmx motif mp3 mpeg ncurses network nls ogg oggvorbis opengl pam pdflib perl plotutils png python qt quicktime readline samba sdl slang spell sse ssl svg tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts vorbis xinerama xml2 xv xvid zlib linguas_nl" Unset: ASFLAGS, CTARGET, LANG, LDFLAGS
Success! USE="nptl" emerge glibc && emerge nvidia-glx ......IT WORKS! glx loads. 'LD_ASSUME_KERNEL=2.4.1 startx' also works! Note that i did: 'USE="nptl"' not 'USE="nptl nptlonly"' amd64 ~ # /lib/tls/libc.so.6 | grep hrea Native POSIX Threads Library by Ulrich Drepper et al Thread-local storage support included. At least I can add nptl to my sig now. Any ideas why? Thanks for the hard work Jeremy!
'Any ideas why?' That wasn't very clear was it? It is 8am though! I mean 'Any ideas why nptl support should make a difference?'
Baz: Can you try this to start X: LD_ASSUME_KERNEL=2.4.1 startx Samuel: this shows that you don't have NPTL... 3) ls -l <the libnvidia-tls.so file listed in #2> ls -l /usr/lib/opengl/nvidia/lib/libnvidia-tls.so.1 lrwxrwxrwx 1 root root 28 Apr 26 21:24 /usr/lib/opengl/nvidia/lib/libnvidia-tls.so.1 -> ../tls-lt/libnvidia-tls.so.1 4) /lib/libc.so.6 | grep hrea linuxthreads-0.10 by Xavier Leroy libthread_db work sponsored by Alpha Processor Inc Thread-local storage support included. 5) /lib/tls/libc.so.6 | grep hrea /lib/tls/libc.so.6: No such file or directory
Quote: 'Baz: Can you try this to start X: LD_ASSUME_KERNEL=2.4.1 startx' This also works!
Baz: yeah... just noticed that... bah.. ;) hmm... I don't know why LD_ASSUME_KERNEL=2.4.1 startx would work on a USE=nptl system but startx wouldn't on a -nptl system. Those ARE the same... Would you miind trying to re-emerge a -nptl glibc just to make sure that was the problem (don't forget, you can 'quickpkg sys-libs/glibc' to make a binpkg of your current state to revert to.
well it MAY be a bug with the linuxthreads version of the lib provided by nvidia... I wish I could see exactly what the differences are, but that lib is provided as a binary **grumble** so as far as I can tell we might be at an endpoint here, and it may need to be addressed further by nvidia.
*** Bug 89986 has been marked as a duplicate of this bug. ***
Quote: 'Would you miind trying to re-emerge a -nptl glibc just to make sure that was the problem (don't forget, you can 'quickpkg sys-libs/glibc' to make a binpkg of your current state to revert to.' Okely-Dokely, why not, its a lovely warm Spring morning here! emerging '-npltl' right now!
or '-nptl' even.
Baz: Thanks... I just want to rule out somethings changing in the glibc ebuild...
Done! 'startx' now works with linuxthreads: glx loaded.......... The plot thickens! amd64 ~ # /lib/tls/libc.so.6 | grep hrea -bash: /lib/tls/libc.so.6: No such file or directory amd64 ~ # /lib/libc.so.6 | grep hrea linuxthreads-0.10 by Xavier Leroy libthread_db work sponsored by Alpha Processor Inc Thread-local storage support included.
'LD_ASSUME_KERNEL=2.4.1 startx' also works, if that helps.
Ah but: if I 'emerge nvidia-glx' after 'USE="-nptl" emerge glibc' startx does NOT work! Looks like you're correct, nvidia-glx is screwing linuxthreads!
It appears that the way to get things working for those who need nvidia-glx is to: 'USE="nptl" emerge glibc', or to do: 'opengl-update xorg-x11', and wait for a resolution to the problem with nvidia-glx and linuxthreads.
Hello Jeremy, tried your ebuilds on a clean linuxthreads glibc 2.3.5 install and found two flaws 1. The opengl-update script copies over the libGL* stuff but NOT the tls lib, resulting in a segfault of glx. On top of that, the wrong path in line 225 I mentioned earlier is still ... well, wrong. 2. nvidia-glx installs the 2320 byte sized tls.so into nvidia/tls-lt - the one X.org is crashing with the whole time. The working one is placed in tls-ntpl.
Sorry for THAT delay... but I needed to get some sleep yesterday. 12 hours at work and then that debugging, that was enough for me. I recompiled glibc as Jeremy suggested with: CFLAGS="march=pentium3 -O2 -pipe" CXXFLAGS="-march=pentium3 -O2 -pipe" USE="ntpl" emerge --oneshot glibc && emerge --oneshot nvidia-glx I enabled the "Load glx" line in xorg.conf and I did an "opengl-update nvidia" and X starts fine. 1) Does X start if you remove 'Load "glx"' from /etc/X/xorg.conf? Yes, it does. 2) ldd /usr/lib/modules/extensions/libglx.so ldd /usr/lib/modules/extensions/libglx.so linux-gate.so.1 => (0xffffe000) libGLcore.so.1 => /usr/lib/opengl/nvidia/lib/libGLcore.so.1 (0xb77f5000) libnvidia-tls.so.1 => /usr/lib/opengl/nvidia/lib/tls/libnvidia-tls.so.1 (0xb77f3000) 3) ls -l <the libnvidia-tls.so file listed in #2> ls -l /usr/lib/opengl/nvidia/lib/tls/libnvidia-tls.so* lrwxrwxrwx 1 root root 25 27. Apr 11:49 /usr/lib/opengl/nvidia/lib/tls/libnvidia-tls.so -> libnvidia-tls.so.1.0.7174 lrwxrwxrwx 1 root root 25 27. Apr 11:49 /usr/lib/opengl/nvidia/lib/tls/libnvidia-tls.so.1 -> libnvidia-tls.so.1.0.7174 -rwxr-xr-x 1 root root 2004 27. Apr 11:49 /usr/lib/opengl/nvidia/lib/tls/libnvidia-tls.so.1.0.7174 4) /lib/libc.so.6 | grep hrea /lib/libc.so.6 | grep hrea linuxthreads-0.10 by Xavier Leroy libthread_db work sponsored by Alpha Processor Inc Thread-local storage support included. 5) /lib/tls/libc.so.6 | grep hrea /lib/tls/libc.so.6 | grep hrea Native POSIX Threads Library by Ulrich Drepper et al Thread-local storage support included. I apologise for the long delay of my report.
Sorry for double posting, forgot to mention: I started X with 'LD_ASSUME_KERNEL=2.4.1 startx' and 'LD_ASSUME_KERNEL=2.4.1 /etc/init.d/xdm restart' as Jeremy told me to do. So, what does that mean? Why does glibc works when it is emerged with USE="ntpl"?
After re-emerging glibc with USE="nptl nptlonly", GLX loads for me too.
David: Re #1) It copies over the libs for linking. libnvidia-tls.so is a private ABI and thus is only used by libglx.so and libGL.so in nvidia's packages, so it's just needed when loading. Thus it's left in the /usr/lib/opengl/<interface>/lib directories David: Re #2) yeah, I got that from Baz's info just now, but the latter should require nptl. It's probably linking fine, but I'm wondering how your framerates are using that lib instead of the other one. Also, it looks like the nptl libnvidia-tls.so does't have a set required OS ABI, so when we were doing 'LD_ASSUME_KERNEL=2.4.1 startx' it was using the one in tls with the linuxthreads libc. So I'm assuming to trigger this bug, we could just do the following on a working USE=nptl system: # rm /usr/lib/opengl/nvidia/lib/tls # LD_ASSUME_KERNEL=2.4.1 startx and maybe even just # rm /usr/lib/opengl/nvidia/lib/tls # startx I'm going to see if I can trigger this now.
yep, it segfaults even with nptl when using the other lib as well. So it definitely looks like an issue to be dealt with upstream, but in the mean time I'm going to investigate the differences between those two libs to see if we can scrap using the broken one. For now, the workaround should be: ln -s ../tls-nptl /usr/lib/opengl/nvidia/lib/tls ldconfig
Created attachment 57410 [details] nvidia-glx-1.0.7174-r3.ebuild Ok, it seems the difference is in whether they enable tls, NOT whether they are optimized for linuxthreads or nptl. Please try this ebuild.
Jeremy: is it necessarry that glibc is emerged with USE="nptl" or not when testing your ebuild?
Juergen: Feedback from both would be good, but it should have no change for nptl users. I'm interested in confirming that this ebuild works "out of the box" with -nptl glibc
OK, I just tested the ebuild and it worked (with an USE="nptl" emerged glibc). Thank you for all your efforts, Jeremy! I'll try re-emergeing glibc WITHOUT the USE="nptl" and I'll report as soon as I can.
Created attachment 57420 [details] PORTDIR_OVERLAY="/local/portdir_overlay" emerge -v nvidia-glx Jeremy: I tried to install your new ebuild (r3) and I hope I've done everything right. Installation is ok, but there is a problem when the opengl-update is called. Please see the attached log file. It's something wrong with the pkg_postrm() routine calling opengl-update --use-old xorg-x11. I believe the option --use-old cannot run with a parameter. Other infos: I don't use an nptl glibc and I can compile and use the new builded nvidia-glx. Thanks! :-)
I don't get any error messages, nvidia-glx-1.0.7174-r3 compiles fine for me. But I don't think that is has something to do with the last line in the ebuild. The error message you get comes much earlier (the information of nvidia is printed out, so the error occures just after removing the old version of nvidia glx). As far as I can see opengl-update nvidia completes successfully: > 0m Switching to nvidia OpenGL interface ...
Jeremy: now I tried the following: "emerge --oneshot glibc && emerge --oneshot nvidia-glx" Those commands gave me back my old glibc (without the nptd USE flag) and nvidia-glx emerged fine. There are no problems in starting X, the glx module loads fine, everything seems to work! Thanks!
Ok, added to cvs... closing. Thanks for your help guys.
Eh, sorry to ask, but are things intended to be fixed now? Because with Xorg still segfaults as other applications like glxgears and mplayer do too. Calculating dependencies ...done! king ~ # emerge --search nvidia-glx nvidia-kernel glibc Searching... [ Results for search key : nvidia-glx ] [ Applications found : 1 ] * media-video/nvidia-glx Latest version available: 1.0.7174-r3 Latest version installed: 1.0.7174-r3 Size of downloaded files: 13,942 kB Homepage: http://www.nvidia.com/ Description: NVIDIA X11 driver and GLX libraries License: NVIDIA * media-video/nvidia-kernel Latest version available: 1.0.7174 Latest version installed: 1.0.7174 Size of downloaded files: 13,942 kB Homepage: http://www.nvidia.com/ Description: Linux kernel module for the NVIDIA X11 driver License: NVIDIA * sys-libs/glibc Latest version available: 2.3.5 Latest version installed: 2.3.5 Size of downloaded files: 15,656 kB Homepage: http://www.gnu.org/software/libc/libc.html Description: GNU libc6 (also called glibc2) C library License: LGPL-2 emerge --info christoph@king ~ $ emerge --info Portage 2.0.51.20-r5 (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.2.5-r2,glibc-2.3.5-r0, 2.6.11-gentoo-r5 i686) ================================================================= System uname: 2.6.11-gentoo-r5 i686 AMD Athlon(tm) XP 2200+ Gentoo Base System version 1.6.11 dev-lang/python: 2.2.3-r5, 2.3.5 sys-apps/sandbox: 1.2.1-r2 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r8 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.11 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O3 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-march=athlon-xp -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig buildpkg ccache distcc distlocks fixpackages sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" LANG="de_DE.utf8" LC_ALL="de_DE.utf8" LINGUAS="de" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowext X aac aalib acpi acpi4linux activefilter adns aim alsa apache2 async audiofile avi bash-completion berkdb bitmap-fonts bluetooth bmp bonobo bzip2 bzlib cddb cdinstall cdparanoia cdr chroot crypt cups curl dga divx4linux doc dvb dvd dvdr eds emboss encode esd evo exif fam fbcon flac foomaticdb fortran ftp gd gdbm gif gimp gimpprint gnome gnomedb gpm gstreamer gtk gtk2 gtkhtml guile hal iconv imagemagick imap imlib imlib2 ipv6 java jikes jpeg junit ldap libg++ libwww live lzw-tiff mad mbox mime mmx mmx2 mmxext mozilla moznocompose moznoirc moznomail mozp3p mozplaintext mozsvg mp3 mpeg mpeg4 msn ncurses netbeans nls nocd nptl ntplonly nvidia ogg oggvorbis openal opengl pam pda pdflib perl php png posix postgres ppds python quicktime readline samba scanner sdl slang smime sockets sox spell sse ssl svg svga tcpd tetex tga tiff truetype-fonts type1-fonts unicode usb vanilla vcd videos vidix vorbis wmf xfs xinerama xml xml2 xosd xpm xv xvid xvmc zlib linguas_de" Unset: ASFLAGS, CTARGET, LDFLAGS, MAKEOPTS
Chris, you are probably experiencing a different bug, so pleas open a new bug report with as much information as possible about your config/bug
*** Bug 90087 has been marked as a duplicate of this bug. ***