SOLVED-Help in CodeBlocks 13.12 and Irrlicht 1.8.1 Setup

[nightrobin]

Good day,
I just want to ask for help in setting up my Codeblocks 13.12 (with CodeBlocks' own MinGW) with Irrlicht 1.8.1, I can't seem to find any useful information/tutorial about it.
And the default Irrlicht Project in Codeblocks seems outdated and not running.
Also I want to know how to set this up manually and step by step.

I have windows 7.

Thanks in advance

[CuteAlien]

Sorry, I thought we had that in the wiki, but can't find it. But I didn't hear about the project beeing outdated - can you please post the exact errors which you get? We can probably help you then.

[nightrobin]

Sorry, I thought we had that in the wiki, but can't find it. But I didn't hear about the project beeing outdated - can you please post the exact errors which you get? We can probably help you then.

The Error Screenshot is here:
http://1drv.ms/1jcDdIA
(I can't upload a picture so I just put a link)

[hybrid]

I think we had those things before already, but any google hit shoudl have helped. Take this one: https://stackoverflow.com/questions/329 ... ity-v0-for
Simply said, you have to use g++ instead of gcc to link, or set up some other compilation flags instead. Most of them are in the example project files, which should work out of the box. So if you just copy those to your own enviroment you should be fine as well.

[CuteAlien]

Also on C::B on Windows it often helps to re-compile the Irrlicht dll (the corresponding project file is in source/Irrlicht). The problem is that there are different g++ versions out there for MinGW which are not compatible to each other. Not sure if that could also cause this specific error.

[Destructavator]

Hi, a C::B (Codeblocks) IDE + MinGW + Irrlicht setup is *exactly* what I work with, so I might be of some assistance here.

I also work with multiple versions and variants of MinGW, so I'm familiar with the differences between some of the versions (but not absolutely all of them, lots of variants are out there and I can't say I've tried every single one).

I would *strongly* recommend using one of the TDM (twilight media dragon) builds of MinGW, not only is it a popular one that is one of the more widely used MinGW packages, but it is one of the easiest to set up and get going with the minimum amount of pain, it supports both a host and platform target of your choice of 32 or 64 bit Windows (meaning that the build environment can be set up and can compile on a 32 or 64 bit Windows machine, and in both situations can build programs targets to run on your choice of 32 or 64 bit Windows, so as such the package is more technically known as a "multi-lib" version). I actually heard recent word direct from the package maintainer / author that he is working on getting a new version out based upon MinGW 4.9.x specs, but until then the build for 4.8.1 is very much rock-solid stable, very reliable, and still modern and current enough for most purposes.

The TDM builds of MinGW are also available on SourceForge, getting the most recent package is very easy with SF's search engine.

Last time I checked the download for C::B IDE can include a TDM build of MinGW, although IIRC the included version is out of date, based upon a 4.7.x build.

Also last time I checked, Irrlicht compiles right out-of-the-box with C::B and MinGW (the recent 4.8.1-based version) with the supplied C::B project and workspace files in the trunk branch of the SVN repo for Irrlicht. I would *think* that this would also apply to the last official release of Irrlicht from the SourceForge download section for the project.

Of course, re-compiling the Irrlicht DLL and the included tutorial projects with such a setup and having it work right assumes that you set up the compiler's .exe files in the proper places in the C::B compiler configuration. If you need help with this, if this is where you are stuck, I'd suggest:

1) Look at the pre-set configuration for standard, old-fasioned 32-bit regular builds of MinGW (which I don't recommend using for a number of reasons). From the main screen of C::B, go to "Settings" then "Compiler...", and you should see the pre-set configuration for "GNU GCC Compiler" already chosen as the first choice to change configuration settings for. Then go to the "Toolchain Execuatables" tab. Note the name of the .exe files for each component, such as "gcc.exe" for C files, "g++.exe" for C++ files, etc. In some cases the pre-set configuration may have filenames prefixed with various different things, so you might see something like "mingw32-gcc.exe" for compiling C files, etc.

2) Once you have an updated version of MinGW, the branch of your choice, you want to either (A) Copy the settings for GNU GCC Compiler and alter the duplicate to work with the new MinGW copy, or (B) just change the existing GCC compiler configuration. When done, it should have the working top-level folder / directory where MinGW is installed (the version you use, of course), not the "bin" directory inside it, but right one step outside of that folder, the path wherever you set up MinGW. You can then use the "..." buttons to automatically open a file browser window where you want to pick the .exe files with similar or matching names, to set up proper compiling, linking, etc.

3) If you still need any help at this stage, just say so and I'll post screen shots.

BTW, the TDM builds of MinGW are very powerful, highly optimized and can potentially build very efficient code. The 64-bit options, based upon the MinGW-w64 project, are especially slick, and are really intelligent in automatically generating optimized machine code when configured properly, code which in some independent tests that I've seen can often compare roughly equal / comparable to Microsoft compilers, sometimes even faster depending on what the code is exactly. Of course, this also greatly depends on your skill at coding to use that potential properly.
The TDM builds also have full support for LTO (Link-Time Optimization), which indeed does work with projects using Irrlicht (just don't try to use such compiler options on the Irrlicht DLL itself, but only projects which import the DLL and use it). You might also be pleased to know that the TDM builds of MinGW also fully support an updated implementation of OpenMP, which allows for very easy and pain-free multi-threading programming. In my own tests, Irrlicht-based games and projects work with OpenMP (libgomp) quite nicely, so if you learn OpenMP you can easily have a multi-threaded main loop in your game that uses all of an end-users computer cores, and automatically adjusts itself depending on whomever runs your final demo / game / program, if you make something you want to distribute to others.

If you have any specific questions on anything I've mentioned, or how to set up or use any of those features, just ask.

EDIT: Please also note, that by default re-compiling the Irrlicht DLL with such a setup doesn't include support for DirectX-based graphics, which means you can either (A) Go with OpenGL, which is cross-platform anyways, or (B) Go through a few extra steps to re-build Irrlicht with full DirectX support (requires some extra downloads from MS, and fiddling with the irrCompileConfig.h header "#define" statements).

[AReichl]

hmmm - with MinGW-TDM i cannot compile some examples from Irrlicht.
I tried a lot of MinGW "distributions", but the most feature complete and problem free (for me) is:

http://sourceforge.net/projects/mingw-w ... gw-builds/

Best use "threads-posix" and then "sjlj".

[nightrobin]

Thanks for all the help you gave, it solved the problem after I compile it

[Destructavator]

hmmm - with MinGW-TDM i cannot compile some examples from Irrlicht.
I tried a lot of MinGW "distributions", but the most feature complete and problem free (for me) is:

http://sourceforge.net/projects/mingw-w ... gw-builds/

Best use "threads-posix" and then "sjlj".

Hmmm.... That's strange, as the last time I recall building Irrlicht and the examples (first the DLL, then the projects), I don't remember having any issues (with TDM). I'm not saying I don't believe you though, part of it might be that with the copy of Irrlicht I use I've modified the source of the Irrlicht engine here and there for my own project's purposes. I also haven't played with the regular, unmodified engine code or examples for a while now, it is possible something may have changed since I last did that.

As for the link you gave, yes, I'm familiar with that one too, I've used the "mingw-builds" distributions before, I remember when they were an independent SF project. Their distributions are also (usually) good, although some releases have bugs that have to be worked around, so in downloading one of their builds the results of using them can be hit or miss. Most of their builds do get the job done, though, and the only real reason some builds work better than others is that they seem to maintain a goal of trying to always keep up with the latest bleeding-edge versions of components. Yes, some of their releases are very powerful, and yes, they pack lots of enabled features in - Some of their 64-bit releases using SEH are especially fast - though for programmers who have limited experience and especially beginners, I often recommend TDM simply because although it might not always be bleeding edge, the TDM package author / maintainer puts a lot of work into making sure that nearly every release is very stable and reliable, working more for a rock-solid release with emphasis on consistent reliability, even if the components are not always the very latest bleeding-edge versions. For someone who really knows what they are doing though, and how to deal with compiler bug issues when they come up, I have nothing against the "mingw-builds" versions.

I still have an SVN client and local copy of the Irrlicht repo on this machine, Just out of curiosity I'll try to re-build the official code projects and see if there's something that should potentially be put on the bugtracker.

Sometime today I'll try to do the same with the last stable release download on SF.

BTW, you *did* try to rebuild the Irrlicht DLL first, before the example projects, yes?

@nightrobin: Glad you got it working! If you need more help later down the road, just ask. Also, if you do happen to use a TDM build (in some cases this also applies to other MinGW builds too), don't forget to read up on the "-m32" and "-m64" switches for controlling if you are building a project intended to run on a target machine running 32 or 64 bit OS. (They need to be sent to *both* the compiler *and* the linker. Many MinGW builds will automatically pick one if you don't specify, which is usually fine when you try out and test code on your own machine, but be aware of how they work if you make something you want to distribute to other people.)

[AReichl]

I don't want to hijack this thread, but ...

With MinGW-TDM example 16 Quake 3 Map Shader would not link ( problem with snprintf ).
On the other side example 21 Quake 3 Explorer ( which also uses snprintf ) compiles and links fine.

I found if i put
#include "driverChoice.h"
ABOVE !!!
#include <irrlicht.h>
it works.

But still - this and other problems with other libraries ( Irrklang, Bullet, Boost, POCO, ... ) i don't have with the distribution i use.

[Destructavator]

I don't want to hijack this thread, but ...

With MinGW-TDM example 16 Quake 3 Map Shader would not link ( problem with snprintf ).
On the other side example 21 Quake 3 Explorer ( which also uses snprintf ) compiles and links fine.

I found if i put
#include "driverChoice.h"
ABOVE !!!
#include <irrlicht.h>
it works.

But still - this and other problems with other libraries ( Irrklang, Bullet, Boost, POCO, ... ) i don't have with the distribution i use.

I can't reproduce the error you mentioned, at least with the latest SVN version 4898, trunk.

I used a fresh SVN checkout, and just opened up the existing workspace in the examples folder.
I had no global switches or special settings sent to the compiler, linker, or anything else, just used out-of-the-box MinGW TDM 4.8.1-3 download, everything default all across the board. (TDM MinGW, by default, will include needed libraries in a static fashion, c++ as well as anything else used, another reason I recommend it to people new to MinGW. Because I didn't add any command-line switches in this case, this also means that "-m64" is implied by default, so in my quick test I'm actually building 64-bit binaries and a 64-bit Irrlicht DLL, but I still wanted to test with everything out-of-the-box and no special configuration set.)

- Irrlicht DLL built just fine, lots of warnings about trying to build without RTTI when compiling the C files for the dependencies, but those are no big deal. I chose "Win32 - accurate math - release - DLL" No errors.

- Built and ran the first four examples, choosing "Windows" for the target of course. No errors, the examples ran just fine.

- Built and ran both examples 16 and 21 you mentioned, both built and ran just fine. No errors, didn't have the issues you mentioned, didn't touch the source code.

- Built the tech demo project. Compiled and linked just fine, just a warning about an unrecognized #pragma statement meant for MSVC compilers (which is no big deal, shouldn't hurt the program). Ran it, no errors. The runtime log did spit out a warning about how an image texture had to be resized, because the source was in oddball dimensions, uneven and not power-of-two, so it made it 128x128, but still used it.

Again, this is with everything out-of-the-box, as if I had just installed everything and didn't change the global compiler settings, didn't add any switches or change any options in C::B. I also didn't touch the irrCompileConfig.h header.

I'm not sure where your problems are coming from, I don't know why you are having a different result.

I admit I didn't do this with the latest official release download from SourceForge, just the most recent SVN checkout. As such, it is possible there may have been some bugs that were fixed since the last release that made the difference in this case.

EDIT: I also didn't try this test with the shader-pipeline branch - Is that what you're using?

EDIT (2): Perhaps we should have another thread for this, one where we discuss Irrlicht with various versions of MinGW and talk about trying to figure out why / how some people are getting inconsistent results.