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

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

"J. Perkins" wrote:

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

Bad fix by the linker? Hmm, doesn't smell good. Sounds like a bug in the
linker, no?

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

I would really prefer the first one too. You should check with the
maintainers of glibc (they have a bug tracking database too I think,
maybe it's already there, and it wouldn't be the first libdl bug I'd
stumble on and get fixed).

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

Q3A does *not* do this. The shell script just switches to the
/usr/local/games/quake3 directory and runs ./quake3.x86, nothing else. I
think that this is after a patch, originally it invoked the quake3.x86
binary with the full path without switching directory (hence the
vid_restart problem I had).

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

If they say they'll fix this, then leave it that way in the mean time...

-- 
"Those who do not understand Unix are condemned to reinvent it,
poorly." -- Henry Spencer