Re: [gut-users] Help with GL setup API?

[Pierre P. <pp...@lu...>]

"J. Perkins" wrote:

> > Ahh, the cascade requirements of libGLU on libGL. What options
> > did you pass to dlopen() when you opened libGL.so?
> 
> I use RTLD_NOW | RTLD_GLOBAL on all shared libraries (those
> interested may refer to Gut/Src/File/sharedlib.cpp).
> 
> The curious thing is that if libGLU.so wasn't able to find the symbols
> in libGL.so, the call to dlopen() should have failed (because of the
> RTLD_NOW flag). But it doesn't fail, which means that the linker
> found all of the symbols it was looking for.

You are right. So it finds its symbols (or so it seems), but *something*
makes it crash later on. Heck, we have source code for libGL.so and
libGLU.so, did you investigate the backtrace? What address exactly
causes the segfault?

> > There *is* a point, (a) is not that true. Sometimes, you have
> > multiple GL libraries (software, 3Dfx, other) laying around and
> > the user would want to choose.
> 
> Is that really the case under Linux? All of the Mesa versions build to
> 'libGL.so' (except v3.0 and earlier, which are buggy and shouldn't be
> used anyway). It might be a useful feature for developers, but it's
> just as easy to symlink libGL.so to the driver you want (which is
> what I do here).

Say you have multiple releases of the nVidia driver?

I have a Mesa 3.2/3Dfx here that came with Quake, which is called
libMesaVoodooGL.so.3.2. Ok, so there is a symlink called libGL.so that
points to it, but did you ever notice that when you link against -lGL,
you are actually require libGL.so.1? A libGL.so link wouldn't even work
(easy to fix, I know).

The real thing is more about multiple libGL.so in different directories.
Like the one that comes with Quake, that is in its own directory. If
quake3.x86 was linked against -lGL, you would need to put the game
directory in LD_LIBRARY_PATH.

> This is still going to be a problem on BeOS. I can't load GL dynamically
> there because I need access to a C++ class contained in the library, and
> as far as I know, there's no way to dynamically load C++ bindings.

You need a C++ class? There is a way to dynamically load C++ code, but
it requires that the library is written in a particular way, which is
probably not the case here.

> Well, Quake doesn't use GLU. If I were writing a game engine (which I
> am actually, but that's a different project), that would be okay. But for
> a general purpose OpenGL library, it doesn't seem acceptable. I could
> build the Mesa GLU directly into the library, that would fix the problem.

True, Quake doesn't use GLU. About the GLU, take note that Mesa will
drop its GLU in favor of the SGI sample implementation GLU. You could do
that also. Take a look at the Linux/OpenGL ABI standard, the have some
stuff to say on that I think.
http://oss.sgi.com/projects/ogl-sample/ABI/

> > Also, I noticed a bug in the way Q3A dlopen OpenGL. You start
> > the game up, it loads the libGL.so from the game directory,
> > but if you restart video (after a configuration change for
> > example), which reloads the libGL, it can't find the very same
> > libGL.so it was using a second before! Something to do with
> > dlopen("libGL.so") vs. dlopen("./libGL.so") vs.
> > dlopen("/usr/local/games/quake3/libGL.so"). The first one uses
> > the /etc/ld.so.conf and the LD_LIBRARY_PATH, the second one
> > only works when in the right directory, and the third one is
> > specific. I know that the second dlopen Q3A does is ./libGL.so,
> > because I know that if I cd to the game directory before
> > running the game, everything is fine.
> 
> That's very strange. Why would they use "./libGL.so" when "libGL.so"
> would work every time?

No, actually, "libGL.so" would *never* work, since it is located in the
game directory of Quake, which isn't in /etc/ld.so.conf, and probably
not in LD_LIBRARY_PATH. I wonder why they're not using the full path all
the time?

-- 
"We aim to make simple things simple and complex things possible."
 -- Alan Kay (on Smalltalk)