Bug 181695

Summary: r300_dri.so driver installed in a wrong place
Product: [Fedora] Fedora Reporter: Pawel Salek <pawsa-gpa>
Component: mesaAssignee: Mike A. Harris <mharris>
Status: CLOSED NOTABUG QA Contact: X/OpenGL Maintenance List <xgl-maint>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-23 00:27:17 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 150222    

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.