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

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

"J. Perkins" wrote:

> > I tried it, but it is linked statically with libMesaGL.so.3 and
> > libMesaGLU.so.3, which is Wrong. I have libGL.so.1 and libGLU.1. If it
> > pretends to be able to select an OpenGL driver at run type, I would have
> > expected it *not* to be linked against *any* OpenGL driver, loading them
> > with dlopen() instead, no?
> 
> Ah, thanks for letting me know about this Pierre. I was in a
> rush to get that demo online so I built it on my laptop, which
> at the time was still running Mesa 3.0 -- before they changed
> to the new library name standards. I usually build on my desktop
> machine, which is up to date.
> 
> Right now, only the Win32 client links OpenGL dynamically. I don't
> do it on the X client for two reasons: a) there's really no point
> that I can see, since "libGL.so" has become a standard, b) I
> couldn't make it work. Here's what would happen:
> 
> 1) at startup I load libGL.so and libGLU.so
> 
> 2) I make a bunch of gl...() calls, everything works fine
> 
> 3) I try to call a glu...() function, say gluPerspective()
> 
> 4) gluPerspective() tries to call glFrustum() and then
> 
> 5) segfault...core dump...
> 
> It appeared that the linker was not properly putting gl() and
> glu() together. I posted some messages around USENET with no
> response, and then I figured I'd yank it because of (a), above.
> 
> Anyway, that's the long answer. I promise never to build against
> an old version of Mesa again. If you build from the sources you
> should be okay.

Ahh, the cascade requirements of libGLU on libGL. What options did you
pass to dlopen() when you opened libGL.so? I know about this problem,
others told me about it. Now take a look at this, from the dlopen man
page:

       External  references in the library are resolved using the
       libraries in that library's dependency list and any  other
       libraries previously opened with the RTLD_GLOBAL flag.  If
       the executable was linked with the flag "-rdynamic",  then
       the  global symbols in the executable will also be used to
       resolve references in a dynamically loaded library.

Now, we don't care for the symbols in the executable, but if I
understand this correctly, if you dlopen libGL.so with RTLD_GLOBAL
(normally not used), the symbols in libGL.so will be used to resolve the
symbols in libGLU.so, right?

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. Sometimes you don't have any GL libraries (a bit like I
was installed). Sometimes you have old GL libraries (named liked
libMesaGL.so for example! ;-) ).

In all those cases, you would want your game to handle this gracefully,
instead of getting an unfriendly message from the dynamic linker. Even
if you don't have GL available, you could pop an Xlib window explaining
the problem in a friendly manner for example, or at least give a console
message that is nice enough.

You wouldn't believe the number of support e-mails we got with the
Win32/DirectX version of Quadra because of the dynamic linker dialog box
(which says something cryptic for a user, like "Unable to load
DINPUT.DLL"). If we could trap this problem, we would have put a simple
MessageBox saying something like "You do not appear to have DirectX
installed, which is required by Quadra. Please go to
http://microsoft.com/directx/ to download and install DirectX.".

I feel that would be a very good feature to have for an OpenGL setup
API. Note the following ldd output on quake3.x86:

[pp@snoopy pp]$ ldd /usr/local/games/quake3/quake3.x86 
        /lib/libNoVersion.so.1 => /lib/libNoVersion.so.1 (0x40015000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4001c000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x400c0000)
        libdl.so.2 => /lib/libdl.so.2 (0x400cc000)
        libm.so.6 => /lib/libm.so.6 (0x400d1000)
        libc.so.6 => /lib/libc.so.6 (0x400ee000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

No OpenGL in sight...

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. I think they
fixed the shell script that runs quake3.x86 to do exactly that by the
way. I guess that the first dlopen uses the full path
(/usr/local/games/quake3 is not in my LD_LIBRARY_PATH or my
/etc/ld.so.conf).

-- 
"World domination. Fast." -- Linus Torvalds