Bugzilla – Bug 14819
xorg-server 1.5.2 fails with nvidia_driver
Last modified: 2009-03-23 14:32:04 UTC
# sorcery -v 20081008 # gaze version xorg-server nvidia_driver mesalib Grimoire Section Spell Grimoire Version Installed Version -------- ------- ----- ---------------- ----------------- test xorg-xserver xorg-server 1.5.2 1.4.2 z-rejected z-kernels nvidia_driver 177.80 177.80 test graphics-libs mesalib 7.2 7.2 When trying to compile xorg-server 1.5.2 (did not try 1.5.1 nor 1.5.0), I receive the following error: Computing previously installed dependencies... xorg-server preparing environment... xorg-server running configuration... [[ Build documentation? -> n ]] [[ Build SHM extension? -> y ]] [[ Install libxf86config? -> y ]] [[ Build XRes extension? -> y ]] [[ Build XInput extension? -> y ]] [[ Build Record extension? -> y ]] [[ Build XDMCP extension? -> y ]] [[ Build XDM_Auth_1 extension? -> y ]] [[ Build GLX extension? -> y ]] [[ Build accelerated indirect GLX? -> y ]] [[ Build GLX with Thread Local Storage support? -> y ]] [[ Build DRI extension? -> y ]] [[ Build Security extension? -> y ]] [[ Build X-ACE extension? -> y ]] [[ Build XC_APPGROUP extension? -> y ]] [[ Build XCalibrate extension? -> y ]] [[ Build TOG_CUP extension? -> y ]] [[ Build Extended-Visual-Information extension? -> y ]] [[ Build Multibuffer extension? -> y ]] [[ Build Xorg server? -> y ]] [[ Build Xvfb server? -> n ]] [[ Build Xnest server? -> y ]] xorg-server provides some advanced EXPERIMENTAL options that may BREAK the build or the final executing of the server. So answer the following carefully [[ Do you wish the advanced options -> n ]] [[ Enable Secure RPC? -> y ]] [[ Build xorgcfg GUI configuration utility? -> y ]] [[ Build kbd_mode utility? -> y ]] [[ Which 100dpi fonts do you want? -> 'all' ]] [[ Which 75dpi fonts do you want? -> 'all' ]] [[ Which Speedo fonts do you want? -> 'none' ]] [[ Which Type1 fonts do you want? -> 'none' ]] [[ Which TTF/OTF fonts do you want? -> 'font-bh-ttf' ]] [[ Which misc fonts do you want? -> 'none' ]] [[ What input drivers do you want -> 'xf86-input-mouse xf86-input-keyboard xf86-input-synaptics' ]] [[ What special input drivers do you want -> 'none' ]] [[ What common video drivers do you want -> 'xf86-video-nv' ]] [[ What uncommon video drivers do you want -> 'none' ]] [[ What obscure video drivers do you want -> 'none' ]] ... gcc -DHAVE_CONFIG_H -I. -I../include -I../hw/xfree86/os-support -I../hw/xfree86/os-support/bus -I../hw/xfree86/common -I../hw/xfree86/dri -I../hw/xfree86/dri2 -I../mi -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I../include -I../include -I../Xext -I../composite -I../damageext -I../xfixes -I../Xi -I../mi -I../miext/shadow -I../miext/damage -I../render -I../randr -I../fb -I/usr/include/drm -I/usr/include/X11/dri -DXFree86Server -DGLX_USE_TLS -DPTHREADS -D__GLX_ALIGN64 -march=nocona -fPIC -DPIC -pipe -DPIC -fPIC -Os -MT rensize.lo -MD -MP -MF .deps/rensize.Tpo -c rensize.c -fPIC -DPIC -o .libs/rensize.o rensize.c: In function '__glXImageSize': rensize.c:227: error: 'GL_DEPTH_STENCIL_MESA' undeclared (first use in this function) rensize.c:227: error: (Each undeclared identifier is reported only once rensize.c:227: error: for each function it appears in.) rensize.c:266: error: 'GL_UNSIGNED_SHORT_15_1_MESA' undeclared (first use in this function) rensize.c:267: error: 'GL_UNSIGNED_SHORT_1_15_REV_MESA' undeclared (first use in this function) rensize.c:281: error: 'GL_UNSIGNED_INT_24_8_MESA' undeclared (first use in this function) rensize.c:282: error: 'GL_UNSIGNED_INT_8_24_REV_MESA' undeclared (first use in this function) make[1]: Leaving directory `/usr/src/xorg-server-1.5.2/glx' make[1]: *** [rensize.lo] Error 1 I found another with the same issue: http://forums.fedoraforum.org/showthread.php?p=1090418 Apparently the 1.5.x series of xorg-server does not play well with the installed nvidia_driver headers. It seems to use the installed headers instead of the included MesaLib headers.
Same problem here, I've searched google and found the same post on fedora forum.
> It seems to use the installed headers instead > of the included MesaLib headers. I think so too, did you try to point to the correct mesalib headers location via configure flags (no nvidia@box here)?
BUILD has: --with-mesa-source=${SOURCE_DIRECTORY}/Mesa-${VERSION2} \ I do not see any other mesa flags in ./configure to use.
dispel nvidia_legacy_173xx cast mesalib (to load include files from cache to system) cast xorg-server cast nvidia_legacy_173xx "fixed" this for me :-)
I think a similar thing got my xorg-server 1.5.2 to compile (somehow it finally updated to 1.5.2), but then my nvidia_driver complained about no libwfb and wouldn't load. Recompiling nvidia_driver didn't help.
A search over the net indicates that he problem with the missing libwfb has been around for a while. nvidia_driver is replacing libwfb.so with a link to a nvidia library. According to nvidia this should only happen when xorg doessn't provide libwfb.so. Anyhow, simply copying the libwfb.so from the cache of xorg-server-1.5.2 over nvidias link solved the problem for me.
For them who have problem: $ gaze from libwfb.so nvidia_legacy_173xx-173.14.12:/usr/lib/xorg/modules/libwfb.so xorg-server-1.5.2:/usr/lib/xorg/modules/libwfb.so $ ls -l /usr/lib/xorg/modules/libwfb.so lrwxrwxrwx 1 root root 48 2008-10-16 10:19 /usr/lib/xorg/modules/libwfb.so -> /usr/lib/xorg/modules/libnvidia-wfb.so.173.14.12
So why is this issue only showing up with xorg-server 1.5.x? If I manually restore /usr/lib/xorg/modules/libwfb.so from xorg-server, overwriting the symlink from nvidia_driver, I get my graphics back. On a box working with xorg-server 1.4.2 and nvidia_driver: $ l /usr/lib/xorg/modules/libwfb.so lrwxrwxrwx 1 root root 45 Oct 16 13:24 /usr/lib/xorg/modules/libwfb.so -> /usr/lib/xorg/modules/libnvidia-wfb.so.177.80 So that symlink is supposed to be there, not the one from xorg-server, but with xorg-server 1.5.2 the symlink breaks X loading. I don't know how xorg-server finally built to 1.5.2, as when I try to cast it I still receive the same error during compilation as originally posted. Also, unrelated to this bug, had to redo my xorg.conf as I no longer has a mouse or keyboard. :(
I don't know why it works with the symlink in 1.4.2, but the following citation from the README for 177.80 <http://us.download.nvidia.com/XFree86/Linux-x86_64/177.80/README/chapter-05.html> clearly shows that the nvidia-installer shouldn't touch libwfl.so. An X module for wrapped software rendering (/usr/X11R6/lib/modules/libnvidia-wfb.so.x.y.z and optionally, /usr/X11R6/lib/modules/libwfb.so); this module is used by the X driver to perform software rendering on GeForce 8 series GPUs. If libwfb.so already exists, nvidia-installer will not overwrite it. Otherwise, it will create a symbolic link from libwfb.so to libnvidia-wfb.so.x.y.z. If I remember right, a rebuild of mesalib but disabling the trigger for rebuilding nvidia_driver, was sufficient to make xorg-server-1.5.2 build for me. I had no problems with keyboard or mice. I don't remember, but maybe my drivers was rebuilt when i upgraded the server.
I didn't have to recast anything to get my keyboard/mouse back, but rather redo my xorg.conf. ;) I found why libwfb is always being overwritten. In nvidia_driver/INSTALL: ln -sfn "$X_MOD/libnvidia-wfb.so.${VERSION/-/.}" \ "$X_MOD/libwfb.so" && I'll fiddle with it a bit and change it to: if [[ ! -f "$X_MOD/libwfb.so" ]]; then ln -sfn "$X_MOD/libnvidia-wfb.so.${VERSION/-/.}" \ "$X_MOD/libwfb.so" fi && I'll see if that works fixes nvidia_driver working without manual intervention (e.g. restoring /usr/lib/xorg/modules/libwfb.so). Casting mesalib and then xorg-server has xorg-server cast fine, and triggers nvidia_driver. Bug #13484 is where the libwfb and libnvidia-wfb files were added to installation. Hrm, removing our installation of libwfb entirely, nvidia_driver *still* overwrites it with a symlink.
Weird, if I remove the installation of libnvidia-wfb.so as well, then /usr/lib/xorg/modules/libwfb.so is removed, but no symlink installed. Ahh, I bet it's because nvidia_driver thinks it owns libwfb.so! My next cast of mesalib, xorg-server and nvidia_driver left libwfb.so as xorg-server's. So the upgrade issue appears to be: 1. xorg-server 1.5.2 now installs a working libwfb.so 2. nvidia_driver overwrote libwfb.so even if it was installed 3. nvidia_driver still thinks it owns libwfb.so and will remove it during dispel, and then redo the symlink (with my fix from Comment #10, or just overwrite it again without the fix) Once nvidia_driver no longer thinks it owns libwfb.so, the fix from Comment #10 works, at least until xorg-server stops installing libwfb.so, then nvidia_driver will install its own and will own it, even when xorg-server is fixed. We still need to figure out how to get the upgrade path to work without futzing. Perhaps remove libwfb.so from nvidia_driver's install log?
According to my install log, xorg-server-1.4.2 also installed libwfb.so. I think that it was by lucky chance that the server worked with the nvidia provided library in 1.4.2. The cited passage from the readme isn't new. Removing libwfb.so from the install log of nvidia_driver will probably do the trick, but if it is done from the nvidia spell, there must be a check that xorg-server is providing libwfb.so (or at least that xorg-server is installed) in case someone really needs the symlink from the nvidia_driver.
Before my changes: # cast -c mesalib xorg-server ... triggers nvidia_driver ... $ gaze from /usr/lib/xorg/modules/libwfb.so nvidia_driver-173.14.12:/usr/lib/xorg/modules/libwfb.so nvidia_driver-177.78:/usr/lib/xorg/modules/libwfb.so nvidia_driver-177.80:/usr/lib/xorg/modules/libwfb.so xorg-server-1.4.2:/usr/lib/xorg/modules/libwfb.so xorg-server-1.5.2:/usr/lib/xorg/modules/libwfb.so $ ls -lah /usr/lib/xorg/modules/libwfb.so lrwxrwxrwx 1 root root 45 2008-10-20 16:12 /usr/lib/xorg/modules/libwfb.so -> /usr/lib/xorg/modules/libnvidia-wfb.so.177.80 =================================================================== After my changes (without manually restoring libwfb.so) in commit 0a598344978946a4dfb037adf998614fd019bb85 in z-rejected: # cast -c mesalib xorg-server ... triggers nvidia_driver ... $ gaze from /usr/lib/xorg/modules/libwfb.so nvidia_driver-173.14.12:/usr/lib/xorg/modules/libwfb.so nvidia_driver-177.78:/usr/lib/xorg/modules/libwfb.so xorg-server-1.4.2:/usr/lib/xorg/modules/libwfb.so xorg-server-1.5.2:/usr/lib/xorg/modules/libwfb.so $ ls -lah /usr/lib/xorg/modules/libwfb.so -rwxr-xr-x 1 root root 219K 2008-10-20 16:54 /usr/lib/xorg/modules/libwfb.so Applied the same fix to nvidia_legacy_173xx with commit 4a371f1dfefb299ff4a9c2e336823777805b798b in z-rejected. The other nvidia video drivers don't seem to install libwfb.
Just a thought...: Maybe it is possible to make xorg-server force a recast on mesalib in case some driver from NVIDIA is installed. Then it hopefully won't break for example at "sorcery system-update". I have also recently noticed that libGL.so.1.2 was missing after installation of nvidia_driver, so that "cleanse --nofix_quick mesalib" reported mesalib as broken, and since mesalib triggered a recast of nvidia_driver, "cleanse --fix" reported mesalib as hopelessly broken.
Closing FIXED bugs.