First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 202978
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: Doug Goldstein <cardoe@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Robert Morell <bobmorell@gmail.com>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 202978 depends on: Show dependency tree
Show dependency graph
Bug 202978 blocks:
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)







View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2007-12-22 03:05 0000
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.

------- Comment #1 From Jeremy Huddleston 2007-12-27 23:29:51 0000 -------
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.

------- Comment #2 From Doug Goldstein 2007-12-28 13:44:18 0000 -------
(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.

------- Comment #3 From Jeremy Huddleston 2007-12-29 20:41:55 0000 -------
ok, then /punt to cardoe

------- Comment #4 From Doug Goldstein 2008-02-15 16:07:01 0000 -------
fixed in 169.09-r1

------- Comment #5 From Doug Goldstein 2008-02-15 17:02:16 0000 -------
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?

------- Comment #6 From Jakub Moc 2008-02-15 21:49:48 0000 -------
*** Bug 210285 has been marked as a duplicate of this bug. ***

------- Comment #7 From Jakub Moc 2008-02-16 14:26:56 0000 -------
*** Bug 210366 has been marked as a duplicate of this bug. ***

------- Comment #8 From Jakub Moc 2008-02-17 10:37:54 0000 -------
*** Bug 210450 has been marked as a duplicate of this bug. ***

------- Comment #9 From Jakub Moc 2008-02-17 10:40:00 0000 -------
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.

------- Comment #10 From Angelo Arrifano (AMD64 AT) 2008-02-17 15:04:04 0000 -------
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

------- Comment #11 From Doug Goldstein 2008-02-17 23:38:00 0000 -------
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.

------- Comment #12 From Robert Golding 2008-02-18 09:47:58 0000 -------
(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

------- Comment #13 From Jakub Moc 2008-02-18 20:34:50 0000 -------
*** Bug 210623 has been marked as a duplicate of this bug. ***

------- Comment #14 From Jonas Bergler 2008-03-04 04:41:04 0000 -------
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.

------- Comment #15 From Doug Goldstein 2008-03-04 04:53:32 0000 -------
Two totally different things..

------- Comment #16 From step 2008-05-24 11:09:41 0000 -------
(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)

First Last Prev Next    No search results available      Search page      Enter new bug