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-184.108.40.206) 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.
Steps to Reproduce:
1. Install =xorg-server-220.127.116.11
2. Install =nvidia-drivers-100.14.23
$ 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 *... ]
$ equery belongs /usr/lib/xorg/modules/libwfb.so
[ Searching for file(s) /usr/lib/xorg/modules/libwfb.so in *... ]
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 18.104.22.168, module version = 1.0.0
ABI class: X.Org ANSI C Emulation, version 0.3
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 22.214.171.124 (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]
dev-java/java-config: 1.3.7, 2.0.33-r1
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
CFLAGS="-march=k8 -Os -msse3 -pipe"
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"
FEATURES="collision-protect distlocks metadata-transfer multilib-strict parallel-fetch sandbox sfperms strict unmerge-orphans userfetch"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
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)