Horde3D

All the internal Horde module state is stored in global variables as pointers. See egModules.cpp.

But those modules are initialized using a call to Modules::init, not using a static constructor. So this shouldn't be a problem as long as nobody calls init using a static constructor call, should it.

Ok, i had the same problem and i solved it.
Just replace the extension loading code utOpengl.{cpp,h} with glew.
Patch for review purposes attached.

That is perhaps a tad drastic...

_________________
Tristam MacDonald - [swiftcoding]

If GLEW works it can't be so difficult to fix the problem. Unfortunately I can't help finding it since I don't have Linux running.

The same stupid workaround works for me, Linux x86/x86_64, Slackware 13.0.

I posted the question to GCC mailing list.

And also to a more appropriate Binutils maling list.

I've run gdb on h3dInit() call which causes the failure.
It appeared that call to glXGetProcAddressARB("glCreateShader") returns 0 when -lGL is the first, and a correct address when -lHorde3D is the first. The function is located in -lGL.
I wonder how this can cause the problem.

It is another manifestation of the same issue we were discussing on the QT thread. Linux/unix linkers are *really* pedantic about link order.

_________________
Tristam MacDonald - [swiftcoding]

Can you please be more concrete? Or point me to the docs?

Well, we maybe could try to resolve the libGL functions (e.g. glXGetProcAddressARB) via dlsym at runtime though.

http://www.opengroup.org/onlinepubs/009 ... dlsym.html

Maybe that way one can work around that issue. Just a guess.

I don't have a reference to docs - it is something I learned in a compiler theory course a couple of years back, and subsequently ran afoul of in my own programming.

Basically, if you are using a single-pass linker (which you generally will be on linux), then the linker has to see references *before* it sees the actual symbol you are referencing. Since libHorde3D references symbols in libGL, -lHorde3D has to be specified before -lGL on link command line.

As phoenix64 mentioned, the dynamic linker doesn't suffer from this. IIRC, this is because you are always loading the referenced symbol into the referencing application.

_________________
Tristam MacDonald - [swiftcoding]

In this case we are 100% using the dynamic linker.

In all implementations I am aware, the OpenGL extension mechanism is just a thin wrapper around dlsym. I am not quite clear what you expect to gain by double indirection here?
Yes, we should be, and if that is indeed the case, then I am not quite sure why this issue is present. However, since changing the link order fixes the issue, clearly there is some linker interaction occurring here that we don't realise.

Perhaps it is a side effect of prelinking? Or maybe the dynamic linker is loading in the wrong order and not correctly patching up the earlier symbol table entries?

_________________
Tristam MacDonald - [swiftcoding]