Bug 181695 - r300_dri.so driver installed in a wrong place
Summary: r300_dri.so driver installed in a wrong place
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: mesa
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: X/OpenGL Maintenance List
URL:
Whiteboard:
Depends On:
Blocks: FC5Blocker
TreeView+ depends on / blocked
 
Reported: 2006-02-15 22:28 UTC by Pawel Salek
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-02-23 00:27:17 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Pawel Salek 2006-02-15 22:28:31 UTC
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):
mesa-libGL-6.4.2-2.1

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 22:48:47 UTC
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 23:09:50 UTC
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 12:19:44 UTC
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.

Thanks.

Comment 4 Mike A. Harris 2006-02-22 04:07:24 UTC
# strings /usr/lib/libGL.so.1.2 |grep usr
/usr/lib/dri


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

rpm -q xorg-x11-server-Xorg mesa-libGL xorg-x11-drv-ati
uname -a

Comment 5 Mike A. Harris 2006-02-22 04:09:46 UTC
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.

TIA

Comment 6 Mike A. Harris 2006-02-22 04:11:36 UTC
Also, attach your X server log and config file, and indicate which architecture
you are using.

Comment 7 Pawel Salek 2006-02-22 07:24:03 UTC
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-23 00:27:17 UTC
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.