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

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

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

I established that it wasn't the code, it was the linker. I tried a number
of different glu...() calls, and they would always fail on the first gl...()
call. The addresses of the gl...() entry points were set incorrectly.



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

Okay, well there are two solutions: fix the linking problems, which frankly
I don't know how to do, or build the Mesa GLU source code directly into
the GUT linux client. I'd really prefer the first solution, but ah well.

Mesa uses the XFree86 license doesn't it? I better check before I
propose that as a solution.


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

That really has nothing to do with GL, since you'd have to do that if
you ship *any* shared libraries with you app. I do, and I get around it
the same way as Q3A: with a shell script which sets LD_LIBRARY_PATH
and launches the game binary.


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

I'm familiar with COM-ish approaches, and no Be didn't do it that way. Be
is about to release a new OpenGL interface which hopefully will fix this
problem, so I'm not going to worry about it right now.



Jason
379