Bug 181695 - r300_dri.so driver installed in a wrong place
r300_dri.so driver installed in a wrong place
Product: Fedora
Classification: Fedora
Component: mesa (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
X/OpenGL Maintenance List
Depends On:
Blocks: FC5Blocker
  Show dependency treegraph
Reported: 2006-02-15 17:28 EST by Pawel Salek
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-22 19:27:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Pawel Salek 2006-02-15 17:28:31 EST
Description of problem:
 r300 drier is installed to /usr/lib/dri/r300_dri.so but apparently the libGL
library expects it to be in /usr/X11R6/lib/modules/dri.

Version-Release number of selected component (if applicable):

How reproducible: Always

Steps to Reproduce:
1. run LIBGL_DEBUG=verbose glxinfo

Actual results:
It prints:
libGL: XF86DRIGetClientDriverName: 4.0.3 r300 (screen 0)
libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r300_dri.so
libGL error: dlopen /usr/X11R6/lib/modules/dri/r300_dri.so failed
(/usr/X11R6/lib/modules/dri/r300_dri.so: cannot open shared object file: No such
file or directory)
libGL error: unable to find driver: r300_dri.so
display: :0  screen: 0
direct rendering: No

Expected results:
It should say "direct rendering: Yes". Xorg.0.log says that DRI is enabled.

Additional info:
Software rendering works on this 32-bit platform.
Comment 1 Pawel Salek 2006-02-15 17:48:47 EST
Just to be one step ahead of possible questions: when I copy the driver to
/usr/X11R6/lib/modules/dri, I get different error:
LIBGL_DEBUG=verbose glxinfo
name of display: :0.0
libGL: XF86DRIGetClientDriverName: 4.0.3 r300 (screen 0)
libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r300_dri.so
libGL error: dlopen /usr/X11R6/lib/modules/dri/r300_dri.so failed
(/usr/X11R6/lib/modules/dri/r300_dri.so: undefined symbol: _glapi_add_dispatch)
libGL error: unable to find driver: r300_dri.so
I am not sure how I can attack that.
Comment 2 Pawel Salek 2006-02-15 18:09:50 EST
Even this second problem is reduced to setting proper search paths properly
because LD_PRELOAD=/usr/lib/libGL.so.1.2  glxgears works just fine.
Comment 3 Mike A. Harris 2006-02-20 07:19:44 EST
The driver is installed in the correct place.  It is libGL looking in the
wrong place for it that is the real problem.  I think there is a bug already
open about this, but I'll add this one to the tracker for now until the dupes
are located.

Comment 4 Mike A. Harris 2006-02-21 23:07:24 EST
# strings /usr/lib/libGL.so.1.2 |grep usr

Please run the above command and paste back the results you get.  Also the

rpm -q xorg-x11-server-Xorg mesa-libGL xorg-x11-drv-ati
uname -a
Comment 5 Mike A. Harris 2006-02-21 23:09:46 EST
For everyone seeing this problem:

Do you have ATI's proprietary fglrx driver installed?

Please run:  rpm -V mesa xorg-x11-server-Xorg

and paste the results, as well as the stuff from comment #4.

Comment 6 Mike A. Harris 2006-02-21 23:11:36 EST
Also, attach your X server log and config file, and indicate which architecture
you are using.
Comment 7 Pawel Salek 2006-02-22 02:24:03 EST
I guess I should start from apologies. No, I have no fglrx installed now - but I
used to. Yes, it was an old library hanging around in /usr/X11R6/lib which was
the reason (I had FC4, upgraded to FC5devel, removed flgrx - which must have
restored the old libGL library)... Everything returned to normal after removing
the old library and /usr/X11R6/lib from /etc/ld.so.conf

I can only hope I did not waste too much of your time...
Comment 8 Mike A. Harris 2006-02-22 19:27:17 EST
Ok, it's good to have tracked it down as I've had several reports of this
problem now.  It seems that they are all red herrings due to 3rd party
drivers blowing away OS provided files.

Please note this is one of the reasons why we do not support 3rd party drivers
even being _installed_ in the OS at all.  They physically blow away our
rpm packaged files, and wipe our libraries/modules out replacing them with
their own copies outside of RPM context.

Even if you decide to use our drivers later, your system is hosed.  People
have difficulty getting their systems to work afterward, and then file bug
reports thinking the OS is to blame.  ;o)

Anyhow, I'll post an email to the fedora lists to let people be aware of this
and to request people to not use proprietary drivers while testing the OS.

Thanks for the update.

Note You need to log in before you can comment on or make changes to this bug.