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

[J. P. <ja...@37...>]

From: Pierre Phaneuf <pp...@lu...>
>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.



>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).


>In all those cases, you would want your game to handle this gracefully,
>instead of getting an unfriendly message from the dynamic linker. 

Okay, now that's a good reason to put it in. But again, I would need to
figure out the linker problem first. 

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.

Another solution to this problem would be to check for your required 
libraries at install time, instead of run time.



>I feel that would be a very good feature to have for an OpenGL setup
>API. Note the following ldd output on quake3.x86:
>(snip)
>No OpenGL in sight...

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.



>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? 

Jason
379