Horde3D

It doesn't - note that I said "out-of-order or circular". The issue is that you must link to Horde first, QT next and OpenGL last, because they depend on each other in that order.

As was alluded to earlier, MSVC (among others) uses a 2-pass linker, so it can find all missing symbols before resolving them, and thus it doesn't care which order the libraries are passed in.

_________________
Tristam MacDonald - [swiftcoding]

Oh, I doubt that is the problem. With shared libraries, the linux linker of course can resolve circular references - it just does not *by default* with static libraries.

"The issue is that you must link to Horde first, QT next and OpenGL last" - as I understood it, it was the exact opposite. See how kornerr linked to Horde3D first, and Horde3D itself links to OpenGL first.

EDIT: It probably rather looks like the dynamic linker drops the reference to libGL.so from the Horde3D lib if there was a reference to it earlier in the executable which causes the GL functions to be redirected or sth like that. And replacing the OpenGL bits with GLEW helps, so that might be a pointer. I really don't know why it is that way, I've compared them, there only were minor differences in how the function to get OpenGL extension addresses was retrieved.

And libHorde3D.so definately links to libGL.so itself, to quote the engine cmake file: "target_link_libraries(Horde3D GL ${HORDE3D_EXTENSION_LIBS})"

EDIT2:
Horde3D:

GLEW:


EDIT3: Oh, and if anyone wants, I have a minimal program showing the problem. With all unnecessary parts stripped away.

EDIT4: I'll try to exchange parts of glew and h3d tomorrow to see what causes the problem.

EDIT5: Enough edited for today, gn8.