Horde3D

By using dlsym to load the libGL.so functions *after* everything was loaded, we might be able work around this? At least that might help with tracking down the problem.

Hi guys.

I stumbled upon the same problem in Linux and unfortunately the link order trick will do for standalone executables like the Knight app.
In our case we use Horde3D inside a shared object and libGL is already in the runtime environment when we dlopen the shared object which links against Horde3D.
I thinkt the whole problem stems from the fact the Horde3D defines its own glCreateShader / glDrawBuffers / ... functions, basically all functions which are not part of OpenGL 1.1. That's no problem for Win32 as symbols don't clash here, because MS OpenGL does not export any functions beyond OpenGL 1.1.
On Linux, however, when linking against libGL we suddenly have symbol clashes, because glCreateShader is defined within libGL (from NVIDIA or ATI or MESA or whatever) and inside libHorde.
So to make a long story short: the trick which worked for us is to put all of Horde's own GL functions (= function pointers) in its own namespace (glExt). Using a hacky "using namespace glExt" within utOpenGL.h one doesn't have to change the gl calls in egRendererBase.cpp.

I already talked about this with Marciano, so you might want to give it a try. The attached patch is against SF SVN rev. 228 and changes utOpenGL.[cpp|h] in a minimal way and works for me both on OSX (where no problem occured anyway) and on Linux (openSUSE 11.2, gcc3/4)

Alex

Hi Alex,

thanks for the patch! It is great to have a simple solution to that problem.