Horde3D

Hi,

I've recently pulled the latest community branch of horde3d+tools and tried opening Horde3DEditor.pro to build. I've set it up to build the Release profile which seems to build up to a point. Horde3D & Utils themselves compile fine using the editor's pro file and they also compile if I import the CMake file into QtCreator as well as the examples. I've pastebin'd what QtCreator pumped out from mingw, it complained about the Quaternions in GLWidget...

Pastebin:
http://pastebin.com/mca0914c

SVN Revision 328 from community branch

Windows XP 64-bit

QtCreator pack 2009.05 (32-bit)
-Qt 4.6
-MinGW 4.4.0 (I think it is this version?)

I'm guessing mingw is a lot more picky than msvc's compiler on this thing, or that I'm using a too modern Qt version? I don't know much C++ enough to fix this, I wanted to experiment with Horde3D's editor by writing some shaders first and export some collada models from maya for some experiments.

Thanks! I've got QtCreator 2009.04 to test as well so I'll try that next.

_________________
-Alex
Website

It seems like the trolls introduced a class QQuaternion in Qt 4.6. The same name is used by the editor in its own quaternion implementation. That's why it's not working with Qt 4.6 right know. But I will try to fix this, as soon as possible although I can't offer you a concrete date. Maybe in the next few hours or at least within the next few days.

Wow what a quick reply, thanks! Ah makes sense, so the name QQuaternion is conflicting with Qt4.6 and your own implementation?

I tried the 2009.04 pack with a lot more success except for when it gets up to lua here:

http://pastebin.com/m34b4198d

No rush on the Qt 4.6 name conflict I'm more than happy to use Qt 4.5.3, or just anything usable for that matter!

Thanks again
-Alex

_________________
-Alex
Website

Hm, the linker errors are a bit strange. It means, that the code compiled fine, but the linker couldn't find some of the methods that should be compiled before. I just did a clean checked out of the community branch and opened the HordeSceneEditor.pro file under trunk/Tools/Horde3DEditor with QtCreator under Ubuntu 9.10 and it worked fine out of the box.
So maybe the toolchain is some kind of broken with MinGW. Unfortunately I don't have a MinGW installation for testing. Maybe you could try to run

in the trunk/Tools/Horde3DEditor folder from the command line without using QtCreator and run

afterwards. Perhaps QtCreator does not work as well as the command line tools.

Ok I've figured out the problem with the linker issues right at the end. It turns out that mingw or the qmake-generated make files makes the right dynamic libs for Lua, Horde3D and Horde3DUtils but it also makes small static libs of these so there's a few .a files in the lib directory. So when the linking stage happens it picks up these small .a files instead of the .dll's and fails. So when the make system failed I deleted the .a files and then continued the compile and it worked!

I can't seem to work out why it makes small static versions of these libs in addition to the proper dlls, from reading the .pro files so I can't find an obvious fix, but a dirty hack for now is to delete the .a files by hand.

This is with QtCreator 2009.04 with its corresponding mingw toolkit and Qt 4.5.3.

_________________
-Alex
Website

Thanks for sharing your fix. I never used MinGW, so I don't know what could be the reason for the .a libraries. Under MSVC the .lib files contains the exported symbols of the DLL to link against without dynamic loading of the DLL at runtime. Not sure if the MinGW compiler tries to create such libs too. If yes, it seems like they don't contain the symbols the should.

But good that you have solved the problem, although the workaround of course shouldn't be necessary.

offtopic: IIRC .a files in MinGW/GCC are equal to the .lib files for MSVC. When you are going to dynamic link them you need both .lib and .dll in MSVC and same happens for MinGW, you need .a and .dll.

I'm not sure but i think it will be a combo of .a and .so for linux. So .a files are not junk and they should be linked in MinGW/GCC like .lib in MSVC.

please correct me if im wrong somewhere

Nope - Under MinGW/Cygwin/Linux/Mac the .a files are static libraries, only used for static linking, while the .dll/,so/.dylib are the dynamic libraries, and don't require any extra files to link.

MSVC has a very strange linker model by comparison

_________________
Tristam MacDonald - [swiftcoding]