People are reporting success with these drivers, so maybe it's somehow related to them being compiled by nvidia with an earlier gcc version... don't see how, but that's my guess right now... X fails to start due to unresolved symbols in nvidia_drv.o (fb and vgahw related) (03:26:48 Sat Jun 12 2004 jeremy@cid) /usr/portage/x11-base/xorg-x11 $ qpkg -I -v nvidia media-video/nvidia-kernel-1.0.5332-r1 * media-video/nvidia-glx-1.0.5332-r2 * (03:27:26 Sat Jun 12 2004 jeremy@cid) /usr/portage/x11-base/xorg-x11 $ emerge info Portage 2.0.50-r8 (gcc34-amd64-2004.1, gcc-3.4.0, glibc-2.3.3_pre20040529-r0, 2.6.5-gentoo-r1) ================================================================= System uname: 2.6.5-gentoo-r1 x86_64 4 Gentoo Base System version 1.4.16 ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CFLAGS="-O2 -pipe -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -pipe -fomit-frame-pointer" DISTDIR="/mnt/raid0/gentoo/distfiles" FEATURES="autoaddcvs ccache cvs fixpackages sandbox userpriv usersandbox" GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/mnt/raid0/gentoo/packages-amd64" PORTAGE_TMPDIR="/mnt/raid0/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/mnt/raid0/gentoo/gentoo-x86" SYNC="rsync://rsync17.us.gentoo.org/gentoo-portage" USE="3ds S3TC X X509 Xaw3d aac aalib accessibility acl acpi activefilter afs aim alsa altivec amd amd64 apache2 apm ardour-ksi arts artswrappersuid atlas audiofile autofs avantgo avi berkdb bidi bindist caps cdr chroot clamav clanJavaScript clanVoice clearpasswd clisp cmucl crypt cscope cups curl dbcp dedicated dga directfb divx4linux dnd doc dv dvd dvdr eim emacs emacs-w3 encode esd ethereal evms2 evo expat ext-png ext-zlib faac faad fam fax fbcon fbdev ffmpeg flac flash fltk fluidsynth foomaticdb freetype fs fullrpc gb gcj gcl gd gd-external gdbm ggi gif gimp gimpprint glade glut gmp gmtfull gmthigh gmtsuppl gmttria gnome gnomedb gnuplot gphoto2 gpm gps gstreamer gtk gtk2 gtkhtml guile hbci icq idl image imagemagick imap imlib imlib2 innodb ipalias ipv6 jabber jack jack-caps javacomm javamail javascript jbig jikes joystick jp2 jpeg js junit justify kde ladcca lcd lcms libdsk libg libg++ libgda libwww lids lmtp log4j ltsp lua lucid lzw lzw-tiff maildir make-busybox-symlinks makecheck mcal md5sum menu mikmod milter mixer mng mono motif mozcalendar mozctl mozilla mozinterfaceinfo mozp3p mozsvg mozxmlterm mpeg mpeg4 mpi mplayer msn mule multilib music mysql nas native ncurses neXt nls nogcj nptl nvidia nviz oav objc oci8 odbc offensive ofx oggvorbis oldworld openal opengl oscar oss pam parse-clocks passfile pcap pcmcia pcre pda pdflib perl php pic pie plotutils png pnp portaudio ppds prelude propolice psyco python qhull qt quicktime readline regexp rplay ruby samba sasl sdk sdl skey slang slp sndfile socks5 sox speex spell sqlite src ssl svg tcltk tcpd tetex theora tiff timidity transcode transparent-proxy truetype trusted type1 ucs2 usb v4l v4l2 vda vhosts videos vim-with-x virus-scan wmf wsconvert wxwin wxwindows xchattext xemacs xface xforms xfs xine xinerama xml xml2 xmms xosd xprint xv xvid yahoo zeo zlib" (03:30:02 Sat Jun 12 2004 jeremy@cid) /usr/portage/x11-base/xorg-x11 $ qpkg -I -v xorg-x11 x11-base/xorg-x11-6.7.0 *
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.