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. > > -Brian > > > -- > _______________________________________________ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > > >
Just a quick FYI... Something has changed in my installation recently (in the last week) to create the need for LD_PRELOAD in games that previously didn't need it. I don't know if it's the 'apt-get upgrade' I did or the upgrade of the Mesa drivers, but suddenly Orbz and MarbleBlast, both of which previously worked fine, now need to be run with LD_PRELOAD. I imagine that this is going to become an even bigger issue as games and applications are added to KDE/Gnome/XFCE menus and users can't figure out why those applications are running so slowly. Adam -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
