On Wed, 2008-02-20 at 14:09 -0500, Kristian Høgsberg wrote: > On Feb 20, 2008 5:20 AM, Michel Dänzer <[EMAIL PROTECTED]> wrote: > > > > On Fri, 2008-02-15 at 09:57 -0500, Kristian Høgsberg wrote: > > > > > > Anyway, the code is out there, shouldn't break anything unless you > > > enable it, [...] > > > > Actually, it looks like you broke at least direct rendering for every > > driver that doesn't provide __dri2DriverInitScreen because that symbol > > is unresolved when libGL tries to dlopen them. > > That doesn't sound right, I haven't touched libGL yet, it doesn't know > anything about DRI2 at this point: > > [EMAIL PROTECTED] mesa]$ grep -i dri2 src/glx/x11/*.[ch] > > Could you provide a few more details?
dri_util.c references __dri2DriverInitScreen and gets linked with the driver. So if the driver doesn't provide __dri2DriverInitScreen, it's unresolved at dlopen time. A possible solution should be to move the DRI2 code to a separate file like dri2_util.c and only link that with DRI2ified drivers. On a possibly related note, someone else (Chris Rankin IIRC) reported that even non-TTM drivers now reference TTM related libdrm symbols. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
