From owner-freebsd-x11@FreeBSD.ORG Tue Jan 25 23:27:41 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6561516A4CE for ; Tue, 25 Jan 2005 23:27:41 +0000 (GMT) Received: from acsrs3.bu.edu (acsrs3.bu.edu [128.197.159.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A12343D2F for ; Tue, 25 Jan 2005 23:27:41 +0000 (GMT) (envelope-from luquette@bu.edu) Received: from localhost (luquette@localhost) by acsrs3.bu.edu (8.13.1/BU_Server-1.3) with ESMTP id j0PNRcTg042728 for ; Tue, 25 Jan 2005 18:27:38 -0500 Date: Tue, 25 Jan 2005 18:27:38 -0500 (EST) From: Lovelace Luquette To: freebsd-x11@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: r200_dri.so fails to load X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2005 23:27:41 -0000 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