Summary: | nvidia drivers failing with USE=pie xorg-x11 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jeremy Huddleston (RETIRED) <eradicator> |
Component: | Current packages | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED UPSTREAM | ||
Severity: | major | CC: | lv, solar |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Xorg.0.log
xorg.conf |
Description
Jeremy Huddleston (RETIRED)
2004-06-12 03:32:17 UTC
Created attachment 33130 [details]
Xorg.0.log
the startup log.
Created attachment 33131 [details]
xorg.conf
Note that when I switch to the 'nv' driver, X starts fine.
Crazy question perhaps... But have you actually loaded the kernel module? Does it report any errors? # modprobe -v nvidia # lsmod I got no errors: nvidia: module license 'NVIDIA' taints kernel. 0: nvidia: loading NVIDIA Linux x86_64 NVIDIA Kernel Module 1.0-5332 Fri Jan 9 12:42:32 PST 2004 d Try a build of xorg-x11 with USE="-pie". yes, setting USE=-pie is a workaround, thanks... but I'm guessing that this will crop up using hardened gcc's as well... is there any way we can get around this? removing amd64@ as it's probably not amd64 specific... The problem is that USE=pie ends up getting you the .so's, while the nvidia binary remains a .o. You'd have to convince nvidia to start providing a .so as well, I think. This isn't a nvidia specific problem. Yesterday I installed Gentoo on my laptop (intel i855) and I also used pie. Everytime I started Xorg it complained about missing symbols in the modules "glx" and "glcore" (and dri because glx wasn't loaded) After recompiling Xorg without "pie" it works flawless. /usr/X11R6/lib/modules/extensions/libGLcore.so: undefined symbol: __glXLastContext /usr/X11R6/lib/modules/extensions/libglx.so: undefined symbol: __glDDXExtensionInfo I can't try this... and won't be able to for a while, but I was wondering... If I understard pic/pie stuff (which I am not too confident about) then nvidia_drv.o had to be compiled -fPIC on amd64 (and might've on x86)... so would doing something like 'gcc -shared -o nvidia_drv.so nvidia_drv.o other.so other.so' work? --- xc/programs/Xserver/GL/mesa/src/X/xf86glx.c 2002-12-17 06:03:24.000000000 +0100 +++ xc/programs/Xserver/GL/mesa/src/X/xf86glx.c 2003-12-30 12:22:34.000000000 +0100 @@ -768,7 +768,6 @@ { XMesaContext xmesa = (XMesaContext) gc->DriverCtx; MESA_CC = NULL; - __glXLastContext = NULL; return XMesaLoseCurrent(xmesa); } ------------------------------------------------ I forget what fixes the other symbol. It may be the load order in the /etc/%s.conf file. ------------------------------------------------ And indeed thats more or less what needs to be done for the 3rd party module. This to be precise. gcc -shared nvidia_drv.o -o nvidia_drv.so \ /usr/X11R6/bin/XFree86 -Wl,-z,defs \ /usr/X11R6/lib/modules/linux/libint10.so \ /usr/X11R6/lib/modules/libvgahw.so \ /usr/X11R6/lib/modules/libfb.so \ /usr/X11R6/lib/modules/libramdac.so \ /usr/X11R6/lib/modules/libddc.so ----------------------------------------------- PIE works great most of the time and even shows some preformance gains despite being 100% PIC. Problem is it just takes awhile for some of these other programs to catch up (like this one). But Thankfully ajax is working towards the dlloader. (so many in a few months??) For now it may be best to remove pie from the IUSE= and comment out any areas in the x11-xorg ebuild to avoid problems users will be having right now if/when trying to use pie. Infact due to the other libbitmap.a bug it may also be ideal to compile with -fno-PIE (but that's still untested) the nvidia driver isnt PIC. wouldnt this cause problems? anyways, it's impossible to use the nvidia driver with X+PIE on amd64. /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.1/../../../../x86_64-pc-linux-gnu/bin/ld: nvidia_drv.o: relocation R_X86_64_32S can not be used when making a shared object; recompile with -fPIC nvidia_drv.o: could not read symbols: Bad value collect2: ld returned 1 exit status yeah.. you can't really fix the 'UPSTREAM' 3rd party module in this case ;/ Probably would have to use the provided nv_drv.so Did anyone ever try getting them to provide .so versions? Nevermind, I just remembered someone telling me it was impossible because of runtime codegen and so forth. tseng probably. Chances are most of this will apply to x86-64 as well and or probably worth tracking upstream if your not already https://freedesktop.org/bugzilla/show_bug.cgi?id=400 Re) comment #13 yes we did. Ans) Not much luck on that front. Solution) I'll send mail again and point to this bug. sent. This bug is sort of a CANTFIX ;/ I'd hope it's more of an UPSTREAM than a CANTFIX myself ;/ More like we CANTFIX-UPSTREAM. We could fix/hack the binary driver one time via reverse engineering for few hrs/days and bit of hex-editing and (dis|re)assembly but we might run into a few legal problems with that. tseng/pax author/ajax/myself and nvidia have been in contact somewhat on this issue but this seems to be on the backburnner for nvidia. However they are aware of the dlloader changes coming up. If you want I can find and fwd the mails in my inbox on the subject if you would like to be/get involved. Yep. |