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. -Brian -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
