On Thu, 2006-06-01 at 11:20 -0600, Brian Paul wrote: > Alan Hourihane wrote: > > On Thu, 2006-06-01 at 17:07 +0100, Alan Hourihane wrote: > > > >>On Thu, 2006-06-01 at 08:53 -0700, Ian Romanick wrote: > >> > >>>-----BEGIN PGP SIGNED MESSAGE----- > >>>Hash: SHA1 > >>> > >>>Jacek Poplawski wrote: > >>> > >>>>On 5/30/06, Pedro Maia <[EMAIL PROTECTED]> wrote: > >>>> > >>>> > >>>>> To run quake2 please use, LD_PRELOAD="path/to/libGL.so" quake2 > >>>>> > >>>>>In my case it works fine, with that trick , without it didn't work. > >>>> > >>>>But why it didn't work? It opens /usr/lib/libGL.so for sure, because > >>>>without > >>>>it even software accelerated OpenGL doesn't work in the game. > >>>>Quake2 is the only application I tried which loads libGL with dlopen. > >>> > >>>I think the way that Quake2 dlopens libGL prevents some symbols in libGL > >>>from being exposed to the driver. I seem to remember alanh mentioning > >>>something about this, but I don't recall the details. My dlopen-fu is > >>>lacking, so I'm not sure what the problem or the solution might be. > >> > >>Basically, what happens is this.... > >> > >>A game may try to dlopen libGL itself at runtime rather than linking at > >>build time. > >> > >>So, the linux dllinker does not bother to search for symbols to resolve > >>that exist in the DRI driver. I'm not sure exactly why it doesn't > >>though. > > > > > > Actually I do remember my theory.... > > > > When a program is linked at build time, libGL is the one responsible for > > dlload'ing the DRI driver and resolves symbols perfectly well with the > > current RTLD flags. > > > > But when the program dlopen's libGL itself, it resolves what it > > currently has access to which the DRI driver isn't actually loaded. I > > suspect for this to work the libGL's dlinit() routine (that's called > > when dlopen'ed) would need to someone link in the correct DRI driver at > > that time - but I'm pretty sure all the available details to do that > > wouldn't be available. > > > > I don't think there's any easy fix, which is why I resorted to the > > LD_PRELOAD approach. > > > > This may all be bogus though. > > This sounds related to the -Bsymbolic linker option. > > When you build a shared library, the -Bsymbolic option tells the > linker to resolve references in the shared library to symbols defined > within the library, in preference to other locations. > > For example, if libGL had a function called init_driver(), -Bsymbolic > would ensure that references to init_driver() were resolved to that > function, and not another init_driver() function that might be defined > in the application itself. > > The lack of -Bsymbolic in some libraries has caused me grief in the > past. I've also raised this issue with some commercial OpenGL vendors.
It can't be this as the libGL we're using now is from Mesa, and mklib already add the -Bsymbolic for us. I'm not sure how the linker can resolve the symbol anyway. The fact that the application has dlopen'ed libGL and the linker doesn't even know which DRI driver to pull in to resolve at that time. Having an unresolvable symbol like _glapi_add_dispatch in libGL without libGL being able to do it's loadable DRI driver first maybe a bad thing. Unless some of the glibc folks can help resolve this one. Alan. -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
