|Summary:||r300_dri.so driver installed in a wrong place|
|Product:||[Fedora] Fedora||Reporter:||Pawel Salek <pawsa-gpa>|
|Component:||mesa||Assignee:||Mike A. Harris <mharris>|
|Status:||CLOSED NOTABUG||QA Contact:||X/OpenGL Maintenance List <xgl-maint>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-02-23 00:27:17 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
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.