Hi everyone, I've been trying now to get a working copy of assimp built for Qt Creator under mingw for the last 2 weekends, I still haven't got something that works and I guess I'm starting to lose all hope here. Can someone please shed some light on how to actually compile and use assimp with mingw…
I've tried building both a static library (.a) and a shared object (.so), using both the mingw copy that ships with Qt and my own installation of mingw. No combination of things I've tries has seemed to work. Initially I only used mingw32-make, but I've now also tried using CMake with little success.
When I build it with the copy of mingw that ships with Qt (GCC4.4), I get no linker or compiling errors, but the library just freezes with CPU use at 100% when I try to load a valid Collada file (which is the main format I want to use), and invalid one seems to fail gracefully, OBJ appears to work based on me outputting some of the data post-load.
When I build it with my own installation of mingw (GCC4.5), I get no compiler errors or linker erros with the library itself, but when I try and link it into my Qt application, I get a lot of errors that say:
Dwarf Error: mangled line number……………
I'm pretty much at the limit of what I can do to try and get it working, can someone please try getting it built using the mingw that ships with Qt (http://get.qt.nokia.com/qtsdk/qt-sdk-win-opensource-2010.04.exe), and confirm that the library built does actually work and load Collada files, then please let me know how you did it cause I seriously can't figure it out.
I know I'm asking a lot here, but please try and help me out here.
- Raz.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I made a small amount of progress, but it's far from ideal. Anyway, this is what I've discovered: By removing the -O3 flag during compilation, the library half works.
With my Qt application compiled in release mode: Application runs and loads Collada files without freezing (with CPU @ 100%)
With my Qt application compiled in debug mode: It now links to an executable that isn't a valid win32 binary!!!
I'm not really sure if I should be happy with this result so far since it seems I've taken one step forward and another backwards, where previously my debug and release mode behaved the same (freezing upon loading a collada file), my debug exe is now completely broken.
And yes, I've tried this experiment twice, recompiling from scratch, same result every time. Not a valid exe in debug, but working in release.
Anyone have any other tricks that might help?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Okay, I've finally managed to solve my problems. All fixes are implemented in makefile.mingw - something I would like to get back into the source tree if possible.
So here is a list of issues I've encountered in the makefile (and fixed):
1) Currently builds with -O3 (highest level of optimization flags, which also includes several unsafe optimizations which in this case breaks Collada support in at least the newer versions of MinGW (GCC 4.4 is version I am using). Building with -O2 is generally recommended since it uses mostly safe optimizations (and it appears to work as expected with my minimal testing).
2) My debug builds linking to a broken executable seems to have come from the 'clean' target not actually cleaning out all directories it should be cleaning out (missed some directories in contrib).
3) Not a show-stopper, but something peculiar that I fixed: release builds were being built with the -g flag (so it compiled objects with debugging in them, it should use -g in debug builds only).
I've uploaded the fixed makefile, if someone wants to sanity-check my changes and commit it to svn that would be great.
Raz.
p.s. The command I used to compile is: mingw32-make.exe -makefile=makefile.mingw NOBOOST=1 static
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
sorry for my late reply, but I was in vacation for some days. Thank you very much for your fix. I will take a look into it and commit it, if it's ok.
Have you tried the CMake-build enviroment as well? If you have some more time you can try this, too in your special enviroment. Fo us it is hard to test our build in any possible way so your infos are really useful to make assimp more stable.
Tnaks and greetings,
Kimmi
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Problems like this make me wonder if we should drop the hand-written Makefiles altogether – somebody using MinGW probably wouldn't mind downloading and installing http://www.cmake.org/files/v2.8/cmake-2.8.2-win32-x86.exe anyway.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, but I couldn't figure out how to use CMake properly. When I tried it, it created both a DLL and a .a, which is really weird since a .a is usually for a static library, so you wouldn't need a DLL right? On top of that, a DLL is not something you would normally build with MinGW, even though you can, usually you would build a .so file… After that confusion I switched back to Make, which is simple and proven to work well. The makefile just needed a few small adjustments to get it working properly.
With regards to CMake, as long as you compile the code on GCC with -O2 everything should be fine. Using -O3 is usually not worth it since it tries to get that little bit of extra performance out of your code but unfortunately ends up breaking things from time to time.
Oh, and my configuration really isn't that unusual :), I'm using GCC 4.4 (from the MinGW copy that ships with Qt, but it's pretty stock standard binaries as far as I can tell).
Take care,
Raz.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Problems like this make me wonder if we should drop the hand-written Makefiles altogether
I don't really see your justification:
* Makefiles are low maintenance since they pick up all the new cpp/c files for you without you having to do anything
* They only need to be altered when you add a new directory to your code tree
* They are extremely common and most people know how they work
* Some flavor of Make is available with just about any compiler
* CMake is an additional tool people need to install and learn how to use (in my case without success)
* Makefiles are simple (most people can pick up the basics of make within a couple of hours from reading tutorials and that knowledge is actually useful in the real world since it is such a common tool)
* They are proven to work well by literally millions of IT projects world-wide.
As I've mentioned earlier, my experience with CMake has been somewhat bumpy. Sure, it looks pretty, but I have not seen a single proper reason why CMake is preferred other than the project generation feature, which you don't need. Also, it ends up using Make anyway, so you aren't replacing one tool with another, you just end up adding another required tool onto your tech stack…
At least that's my 2 cents.
Raz.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, the reason why I personally do not like having multiple build systems in the main repository is simple: maintainability. Having to update multiple build systems which you personally can't even use (e.g. MSVC when you are on Linux or Mac, etc.) when you add/rename/remove something in the code tree, or at least to verify that stuff still works can be a real pain.
In most cases, this leads to untested and/or outdated build files lying around in the source repository, which can be very frustrating to end users, as you have probably experienced yourself. Having a build system that works on virtually all systems (CMake can also generate Visual Studio and XCode project files, that's the reason why our CMakeFiles list every file by hand) should alleviate these problems.
Besides, I am pretty sure that CMake actually worked for you. If I remember correctly – it has been quite some time since I used CMake with MinGW myself –, the .a file is simply an import library for the DLL, so simply adding »-lassimp« to your linker flags should work. If you want to have a static library, set the BUILD_SHARED_LIBS flag to OFF (via the command line, ccmake or cmake-gui).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My problem didn't come from make though. If I was using cmake I would have run into the same thing since that also attempted to build with -O3 if memory serves which is the main cause of my problems. Hopefully the powers that be will listen and update the scripts so they only use the safer optimizations. I mean performance is good and all, but when you can't guarantee it will work as a result you have to wonder.
The other changes were nice to haves but not essential.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
gcc (GCC) 4.4.0
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi everyone, I've been trying now to get a working copy of assimp built for Qt Creator under mingw for the last 2 weekends, I still haven't got something that works and I guess I'm starting to lose all hope here. Can someone please shed some light on how to actually compile and use assimp with mingw…
I've tried building both a static library (.a) and a shared object (.so), using both the mingw copy that ships with Qt and my own installation of mingw. No combination of things I've tries has seemed to work. Initially I only used mingw32-make, but I've now also tried using CMake with little success.
When I build it with the copy of mingw that ships with Qt (GCC4.4), I get no linker or compiling errors, but the library just freezes with CPU use at 100% when I try to load a valid Collada file (which is the main format I want to use), and invalid one seems to fail gracefully, OBJ appears to work based on me outputting some of the data post-load.
When I build it with my own installation of mingw (GCC4.5), I get no compiler errors or linker erros with the library itself, but when I try and link it into my Qt application, I get a lot of errors that say:
Dwarf Error: mangled line number……………
I'm pretty much at the limit of what I can do to try and get it working, can someone please try getting it built using the mingw that ships with Qt (http://get.qt.nokia.com/qtsdk/qt-sdk-win-opensource-2010.04.exe), and confirm that the library built does actually work and load Collada files, then please let me know how you did it cause I seriously can't figure it out.
I know I'm asking a lot here, but please try and help me out here.
- Raz.
I made a small amount of progress, but it's far from ideal. Anyway, this is what I've discovered: By removing the -O3 flag during compilation, the library half works.
With my Qt application compiled in release mode: Application runs and loads Collada files without freezing (with CPU @ 100%)
With my Qt application compiled in debug mode: It now links to an executable that isn't a valid win32 binary!!!
I'm not really sure if I should be happy with this result so far since it seems I've taken one step forward and another backwards, where previously my debug and release mode behaved the same (freezing upon loading a collada file), my debug exe is now completely broken.
And yes, I've tried this experiment twice, recompiling from scratch, same result every time. Not a valid exe in debug, but working in release.
Anyone have any other tricks that might help?
Just a few more notes, in case this helps:
1) Using the NOBOOST=1 flag when compiling
2) Using the mingw makefile
3) Building to a static library
Okay, I've finally managed to solve my problems. All fixes are implemented in makefile.mingw - something I would like to get back into the source tree if possible.
So here is a list of issues I've encountered in the makefile (and fixed):
1) Currently builds with -O3 (highest level of optimization flags, which also includes several unsafe optimizations which in this case breaks Collada support in at least the newer versions of MinGW (GCC 4.4 is version I am using). Building with -O2 is generally recommended since it uses mostly safe optimizations (and it appears to work as expected with my minimal testing).
2) My debug builds linking to a broken executable seems to have come from the 'clean' target not actually cleaning out all directories it should be cleaning out (missed some directories in contrib).
3) Not a show-stopper, but something peculiar that I fixed: release builds were being built with the -g flag (so it compiled objects with debugging in them, it should use -g in debug builds only).
I've uploaded the fixed makefile, if someone wants to sanity-check my changes and commit it to svn that would be great.
Raz.
p.s. The command I used to compile is: mingw32-make.exe -makefile=makefile.mingw NOBOOST=1 static
Hi Raziel2001au,
sorry for my late reply, but I was in vacation for some days. Thank you very much for your fix. I will take a look into it and commit it, if it's ok.
Have you tried the CMake-build enviroment as well? If you have some more time you can try this, too in your special enviroment. Fo us it is hard to test our build in any possible way so your infos are really useful to make assimp more stable.
Tnaks and greetings,
Kimmi
Problems like this make me wonder if we should drop the hand-written Makefiles altogether – somebody using MinGW probably wouldn't mind downloading and installing http://www.cmake.org/files/v2.8/cmake-2.8.2-win32-x86.exe anyway.
Sorry, but I couldn't figure out how to use CMake properly. When I tried it, it created both a DLL and a .a, which is really weird since a .a is usually for a static library, so you wouldn't need a DLL right? On top of that, a DLL is not something you would normally build with MinGW, even though you can, usually you would build a .so file… After that confusion I switched back to Make, which is simple and proven to work well. The makefile just needed a few small adjustments to get it working properly.
With regards to CMake, as long as you compile the code on GCC with -O2 everything should be fine. Using -O3 is usually not worth it since it tries to get that little bit of extra performance out of your code but unfortunately ends up breaking things from time to time.
Oh, and my configuration really isn't that unusual :), I'm using GCC 4.4 (from the MinGW copy that ships with Qt, but it's pretty stock standard binaries as far as I can tell).
Take care,
Raz.
I don't really see your justification:
* Makefiles are low maintenance since they pick up all the new cpp/c files for you without you having to do anything
* They only need to be altered when you add a new directory to your code tree
* They are extremely common and most people know how they work
* Some flavor of Make is available with just about any compiler
* CMake is an additional tool people need to install and learn how to use (in my case without success)
* Makefiles are simple (most people can pick up the basics of make within a couple of hours from reading tutorials and that knowledge is actually useful in the real world since it is such a common tool)
* They are proven to work well by literally millions of IT projects world-wide.
As I've mentioned earlier, my experience with CMake has been somewhat bumpy. Sure, it looks pretty, but I have not seen a single proper reason why CMake is preferred other than the project generation feature, which you don't need. Also, it ends up using Make anyway, so you aren't replacing one tool with another, you just end up adding another required tool onto your tech stack…
At least that's my 2 cents.
Raz.
Well, the reason why I personally do not like having multiple build systems in the main repository is simple: maintainability. Having to update multiple build systems which you personally can't even use (e.g. MSVC when you are on Linux or Mac, etc.) when you add/rename/remove something in the code tree, or at least to verify that stuff still works can be a real pain.
In most cases, this leads to untested and/or outdated build files lying around in the source repository, which can be very frustrating to end users, as you have probably experienced yourself. Having a build system that works on virtually all systems (CMake can also generate Visual Studio and XCode project files, that's the reason why our CMakeFiles list every file by hand) should alleviate these problems.
Besides, I am pretty sure that CMake actually worked for you. If I remember correctly – it has been quite some time since I used CMake with MinGW myself –, the .a file is simply an import library for the DLL, so simply adding »-lassimp« to your linker flags should work. If you want to have a static library, set the BUILD_SHARED_LIBS flag to OFF (via the command line, ccmake or cmake-gui).
P.S.: The »plain old unix« equivalent to CMake would not be make, but rather autotools…
My problem didn't come from make though. If I was using cmake I would have run into the same thing since that also attempted to build with -O3 if memory serves which is the main cause of my problems. Hopefully the powers that be will listen and update the scripts so they only use the safer optimizations. I mean performance is good and all, but when you can't guarantee it will work as a result you have to wonder.
The other changes were nice to haves but not essential.
Seems fine to me. Committed as r808.
Bye & thanks, Alex
Could you please post the exact version of GCC you are using (gcc -version)?
I personally have not had any problems with -O3 so far, and CMake also uses it as default for Release builds.
gcc (GCC) 4.4.0
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.