On Mon, 2006-07-24 at 07:21 -0700, Ian Romanick wrote: > > > The attached patch attempts to fix this in libGL by always dlopening > > libGL itself with RTLD_GLOBAL before trying to dlopen the driver, and > > dlclosing the handle obtained from dlopening libGL again before > > returning. It works here, e.g. tremulous and slune now get direct > > rendering without LD_PRELOAD=libGL.so.1 again. > > Ah. Very clever. I was thinking about solving this a different way. > We have a way to get function pointers into the driver from the loader. > I was thinking that we could use one of these mechanisms (either > passing it in via the interface structure or via the getProcAddress > method) to get the _glapi_* functions. > > That said, your patch is much lower impact, and I like it.
Thank you. The impact is most definitely lower from an implementation POV, but I'm wondering if the dlopen with RTLD_GLOBAL could have any undesirable side effects; maybe the problematic apps have a reason not to dlopen libGL with RTLD_GLOBAL. My gut feeling is that there shouldn't be though; I can't think of a scenario where the symbols exported by libGL would need to be resolved elsewhere. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
