The NVIDIA drivers ship with libnvidia-wfb.so, and our default installer installs this (and add a symlink from libwfb.so) in X's modules directory if libwfb.so does not already exist as a regular file. NVIDIA only does this because we need this module on old servers which don't include it by default. libwfb.so is needed by the nvidia driver for G80 and newer GPUs, even if OpenGL is not being used (libwfb is used to perform arbitrary transformations so X's software rendering fallbacks can work on nonlinear surfaces). Newer X servers ship with their own libwfb.so, which should replace the one NVIDIA ships in case the xorg folks add any bugfixes or new rendering operations upstream. What happens with portage (at least on my ~x86 system) is that NVIDIA's libwfb.so is added as part of the nvidia-drivers install to /usr/lib/opengl/nvidia/extensions/, and symlinked into /usr/lib/xorg/modules/extensions/ when eselecting the NVIDIA OpenGL implementation. The X server's libwfb.so (I have x11-base/xorg-server-1.4.0.90) is installed into /usr/lib/xorg/modules/. In practice (at least on this server), this works out because the default module search path looks in the modules directory before the modules/extensions directory, so X always loads the libwfb.so it shipped with. However, if an older server were to be installed which does not ship its own libwfb.so, and the xorg-x11 OpenGL implementation eselect'ed on a system with a G8x-based GPU, the X server would fail to start with the nvidia driver since it wouldn't be able to load libwfb.so. libwfb.so was first shipped with xorg-server 1.3, so the =xorg-server-1.2.0-r3 package will have this problem. Reproducible: Always Steps to Reproduce: 1. Install =xorg-server-1.4.0.90 2. Install =nvidia-drivers-100.14.23 Actual Results: $ ls -l /usr/lib/xorg/modules/extensions/libwfb.so lrwxrwxrwx 1 root root 43 Dec 21 17:53 /usr/lib/xorg/modules/extensions/libwfb.so -> /usr/lib/opengl/nvidia/extensions/libwfb.so $ ls -l /usr/lib/xorg/modules/libwfb.so -rwxr-xr-x 1 root root 190616 Dec 19 22:35 /usr/lib/xorg/modules/libwfb.so $ equery belongs /usr/lib/opengl/nvidia/extensions/libwfb.so [ Searching for file(s) /usr/lib/opengl/nvidia/extensions/libwfb.so in *... ] x11-drivers/nvidia-drivers-100.14.23 (/usr/lib/opengl/nvidia/extensions/libwfb.so) $ equery belongs /usr/lib/xorg/modules/libwfb.so [ Searching for file(s) /usr/lib/xorg/modules/libwfb.so in *... ] x11-base/xorg-server-1.4.0.90 (/usr/lib/xorg/modules/libwfb.so) Excerpt from /var/log/Xorg.0.log: (II) Loading sub module "wfb" (II) LoadModule: "wfb" (II) Loading /usr/lib/xorg/modules//libwfb.so (II) Module wfb: vendor="X.Org Foundation" compiled for 1.4.0.90, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.3 Expected Results: Only one libwfb.so should be installed, and it should be installed as part of either: a) xorg-server installation (overrides any provided by nvidia-drivers) b) nvidia-drivers installation, if xorg-server does not provide one Neither should be removed as part of 'eselect opengl' operation. I am an NVIDIA employee who works on the nvidia UNIX driver. Feel free to contact me if you have any questions.
Thanks for the detailed report, Robert. I think probably the cleanest solution for this is to just change the nvidia-drivers version dep to >=xorg-server-1.3 and not ever provide the nvidia-provided libwfb. If anyone has an objection (such as some reason they NEED xorg-server-1.2), speak now or I'll be doing this in a few days.
(In reply to comment #1) > Thanks for the detailed report, Robert. > > I think probably the cleanest solution for this is to just change the > nvidia-drivers version dep to >=xorg-server-1.3 and not ever provide the > nvidia-provided libwfb. If anyone has an objection (such as some reason they > NEED xorg-server-1.2), speak now or I'll be doing this in a few days. > Please don't touch the nvidia-drivers ebuild, eradicator.
ok, then /punt to cardoe
fixed in 169.09-r1
Actually the more I read into this... If X ships with libwfb.so, it would be found in.. /usr/lib/xorg/modules/ and that path is searched first. So it'll load the libwfb.so that ships with X.org server. If X does not ship with libwfb.so, it would look in /usr/lib/xorg/modules/ and not find it. Then it would check /usr/lib/xorg/modules/extensions/ where it would find the libwfb.so provides by NVIDIA. Is this not the expected and desired behavior?
*** Bug 210285 has been marked as a duplicate of this bug. ***
*** Bug 210366 has been marked as a duplicate of this bug. ***
*** Bug 210450 has been marked as a duplicate of this bug. ***
Great; so - until this change, we got exactly zero bugs about libwfb.so. Since this 'issue' has been 'fixed' in latest version, we got 3 bugs about the thing being broken. I'd suggest reverting the change and marking this bug as INVALID since fixing it only caused regressions without any good reason - all is stated in Comment #5 after all.
I've synced today and updated to nvidia-drivers-169.09-r1. Xorg refused to start due to missing /usr/lib64/xorg/modules/extensions/libwfb.so which is a symlink by eselect from /usr/lib64/opengl/nvidia/extensions/libwfb.so The problem is that nvidia-drivers doesn't provide libwfb.so but libnvidia-wfb.so.169.09 instead. If this was supposed to be fixed, I'm still having this problem.. $ ls -l /usr/lib64/xorg/modules/extensions -rwxr-xr-x 1 root root 18616 2008-02-17 14:14 libdbe.so -rwxr-xr-x 1 root root 127064 2008-02-17 14:14 libextmod.so -rwxr-xr-x 1 root root 2071928 2008-02-17 14:14 libGLcore.so lrwxrwxrwx 1 root root 45 2008-02-17 14:14 libglx.so -> /usr/lib64/opengl/nvidia/extensions/libglx.so -rwxr-xr-x 1 root root 26952 2008-02-17 14:14 librecord.so lrwxrwxrwx 1 root root 46 2008-02-12 18:03 libwfb.so -> //usr/lib64/opengl/nvidia/extensions/libwfb.so -rwxr-xr-x 1 root root 43584 2008-02-17 14:14 libxtrap.so $ ls -l /usr/lib64/opengl/nvidia/extensions -rwxr-xr-x 1 root root 1041000 2008-02-17 01:04 libglx.so -rwxr-xr-x 1 root root 285376 2008-02-17 01:04 libnvidia-wfb.so.169.09 - - Portage 2.1.4.4 (default-linux/amd64/2007.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.23-gentoo-r3 x86_64) ================================================================= System uname: 2.6.23-gentoo-r3 x86_64 AMD Turion(tm) 64 X2 Mobile Technology TL-56 Timestamp of tree: Sat, 16 Feb 2008 19:00:01 +0000 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.0.33-r1 dev-lang/python: 2.4.4-r6 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.10-r5 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -Os -msse3 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=k8 -Os -msse3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="collision-protect distlocks metadata-transfer multilib-strict parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://213.186.33.37/gentoo-distfiles/" LANG="en_US" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X a52 aac acpi alsa amd64 amr amrnb amrwb bash-completion berkdb bitmap-fonts branding bzip2 cairo cli cracklib crypt cups dbus divx doc dvd dvdr emerald fam ffmpeg firefox flac fortran gd gdbm gif glade glib glitz gtk gtkspell hal hddtemp iconv imagemagick insecure-savers isdnlog javascript jpeg jpeg2k kqemu libcaca libnotify midi mmx mmxext mp2 mp3 mp4 mpeg mplayer mudflap musicbrainz mysql ncurses nls nptl nptlonly offensive ogg opengl openmp pam pcre png pppd python quicktime readline realmedia reflection samba sdl session smp spell spl sse sse2 ssl stream svg syslog taglib tcpd threads truetype truetype-fonts type1 type1-fonts unicode v4l v4l2 vhosts vim-syntax vorbis wifi wmp xcomposite xorg xosd xpm xscreensaver xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev synaptics joystick" KERNEL="linux" LCD_DEVICES="xosd" USERLAND="GNU" VIDEO_CARDS="nv nvidia none" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Currently -r1 is configured per Robert Morell and Jeremy Huddleston's request. I don't have access to a committing machine on Saturday and Sunday, however I'll revert it Monday morning.
(In reply to comment #9) > Great; so - until this change, we got exactly zero bugs about libwfb.so. Since > this 'issue' has been 'fixed' in latest version, we got 3 bugs about the thing > being broken. > > I'd suggest reverting the change and marking this bug as INVALID since fixing > it only caused regressions without any good reason - all is stated in Comment > #5 after all. > Now mine makes four bugs, and I know of a few others that haven't put bugs in (already entered, is their excuse) as well, so thats nearly a dozen. Oh My Dog, that's almost a movement ... The WFB Don't Work Alliance :-) Quick fix for those who want to, package mask 169.09-r1 and revert to 169.09
*** Bug 210623 has been marked as a duplicate of this bug. ***
It appears this still affects 169.12. The fix for me was simple in that I had to run 'eselect opengl set nvidia' after emerging the driver ebuild.
Two totally different things..
(In reply to comment #14) > It appears this still affects 169.12. The fix for me was simple in that I had > to run 'eselect opengl set nvidia' after emerging the driver ebuild. > thank you Jonas Bergler, works for me (x11-drivers/nvidia-drivers 169.09-r1(12:46:46 05/24/08)
