|
OK, this one is kicking my rear end. At work we have an Open Inventor app we've had going back to the days when we used SGI hardware. I have to point out that we have always compiled our software into static archives and linked our executables against them. As a science project I'm trying to get them to link against .so versions of the same libraries. Now this app works perfectly fine linking against the static libraries. But when I link it against the shared objects, it crashes about 40 levels deep in the Inventor SoXt::mainLoop(). I've tracked the reason for the crash to a NULL returned by glGetString(GL_VENDOR). Google tells me that this is usually caused by not having a valid GL context at the point of the call. But I *think* there is one in this case, or at least, glXGetCurrent() returns something that appears reasonable; and as I said, it works fine when using the static libraries. So what's going on here? In both cases the code is identical, and it's using the same Inventor and GL libraries, but one way crashes and the other doesn't.
|
#
¿
Feb 27, 2012 05:52
|
|
|
|
| # ¿ Apr 26, 2024 10:02 |
|
|
pseudorandom name posted:Does glGetError() return anything useful after the glGetString() returns 0?
|
|
#
¿
Feb 27, 2012 22:13
|
|
|
Spite posted:Firstly, what has changed since it used to work? Nothing has changed. The only difference is linking .so versions of our libraries instead of the .a versions. quote:Do other gl calls work? I should point out that I have no idea how to do any of this. This app was written back in the Bronze Age. The big chunk of the display is an SoXtRenderArea. If I comment out the show() call for that object, the app no longer crashes; but then of course all I get is a black window. glGetCurrentContext() works. quote:Can you call glGetString(GL_RENDERER) or GL_VERSION or GL_EXTENSIONS? quote:Also it occurs to me that you may not be creating the context correctly in the dynamically linked case. How is the context created? Are you using glXGetProcAddress, etc? Does that return valid function pointers?  The context is created at the point where the show() method is called on the SoXtRenderArea. Before that point, glGetCurrentContext() returns null. After that it returns what looks like a valid pointer. This behavior is the same for both the crashing and non-crashing cases.EDIT: I removed all the children from the render area and replaced it all with a single SoCube object. It still crashes. Presto fucked around with this message at 19:28 on Feb 28, 2012 |
|
#
¿
Feb 28, 2012 17:59
|
|
|
Spite posted:Sounds like you don't have a context. I'm not sure why that would occur and I don't have much experience with xwin. The context is created in the Open Inventor code. I've put the glGetString call at that point, immediately after the context is created and made current, and it still returns NULL. I also found out that glGetIntegerv also doesn't work properly in the shared link case. For instance glGetIntegerv(GL_MAX_LIGHTS) returns a big negative number (something like -272716322) instead of the 8 it returns when it works. It's almost like some static memory in libGL.so isn't being initialized or something. I've also run the whole thing in valgrind and Insure++ and didn't turn up any smoking guns. Edit: What the poo poo? If I call the function through the pointer returned by glXGetProcAddress it works. Presto fucked around with this message at 00:06 on Mar 2, 2012 |
|
#
¿
Mar 1, 2012 23:39
|
|
|
Got the fucker. In the static link case, glXGetProcAddress("glGetString") and the address of the bare glGetString symbol returned the same pointer, but in the shared object care they didn't. I added a '-y glGetString' option to the link command, and it turned out that one of our local libraries requires OSMesa, and libOSMesa.so also defines a bunch of gl calls, and the symbols were being linked from there instead of from libGL. I moved the OSMesa library to the end of the link line and it's all good now. Thanks for the suggestions.
|
|
#
¿
Mar 2, 2012 01:43
|
|