Date: Tue, 25 Jan 2005 18:27:38 -0500 (EST) From: Lovelace Luquette <luquette@bu.edu> To: freebsd-x11@freebsd.org Subject: r200_dri.so fails to load Message-ID: <Pine.A41.4.58.0501251823240.231808@acsrs3.bu.edu>
next in thread | raw e-mail | index | archive | help
Hi, I'm currently trying to debug the Nintendo64 emulator (mupen64) video plugin named glN64; however, the plugin crashes miserably on any call to glDrawArrays. Debugging that particular function is outside the scope of this email. Hoping for clues, I set LIBGL_DEBUG to verbose before running mupen64, and got the following: %setenv LIBGL_DEBUG verbose %mupen64 [glN64]: (II) Initializing SDL video subsystem... [glN64]: (II) Getting video info... [glN64]: (II) Setting video mode 640x480... libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r200_dri.so libGL error: dlopen /usr/X11R6/lib/modules/dri/r200_dri.so failed (/usr/X11R6/lib/modules/dri/r200_dri.so: Undefined symbol "_glapi_Dispatch") libGL error: unable to find driver: r200_dri.so This wasn't exactly what I was expecting to learn from LIBGL_DEBUG, but it was interesting none the less. Running glxgears with LIBGL_DEBUG still set as verbose gave me: %glxgears libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r200_dri.so drmOpenByBusid: Searching for BusID pci:0000:01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 Indicating no such problem loading the r200 DRI module. Moreover, I checked libGL.so for traces of the function: %strings /usr/X11R6/lib/libGL.so|grep Dispatch _glapi_RealDispatch _glapi_DispatchTSD _glapi_Dispatch _gl_DispatchTSD _glapi_RealDispatch _glapi_DispatchTSD !DispatchOverride _glapi_Dispatch is certainly there. I supposed I may have misunderstood mupen64's move to a native FreeBSD format, so I double checked the branding on the mupen ELF. Sure enough, it's a FreeBSD ELF. %elfdump -e /usr/local/libexec/mupen64|grep e_ident e_ident: ELFCLASS32 ELFDATA2LSB ELFOSABI_FREEBSD So mupen64 won't be trying to load Linux DRI modules---which could have explained the success of glxgears and the failure of mupen64. As a final note, direct rendering is enabled and working correctly as the glxgears output implies. Any ideas on why mupen64's attempt to load r200_dri.so fails to load the driver? Joe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.A41.4.58.0501251823240.231808>