Skip site navigation (1)Skip section navigation (2)
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>