[no bug] Irrlicht 1.8 SIGSEGV when calling getDriver

[Cube_]

For some reason

Code: Select all

E:\Softwarez\CodeBlocksPortable\Projects\irrlicht-1.8\irrlicht-1.8\source\Irrlicht\CSoftwareDriver2.cpp|1536|warning: 'sourceIndex' may be used uninitialized in this function [-Wuninitialized]|
[u]E:\Softwarez\CodeBlocksPortable\Projects\irrlicht-1.8\irrlicht-1.8\source\Irrlicht\CSoftwareDriver2.cpp|1511|note: 'sourceIndex' was declared here|[/u]

Is treated like an error.
Also, for some other unknown reason -wall is enabled by default, a flag I really dislike *It always misbehaves*
Compilation seems to work with -wall disabled.
Going to try running irrlicht again.

For some reason compiling without -wall works, and this lib is functioning.
Although I can't see why on earth -wall would treat notes as errors, nor do I see why using the c++0x standard would cause problems.

[hendu]

You have -Werror somewhere. (treat warnings as errors.)

[hybrid]

-Wall should be always on for every project, as it shows the most likely problems in your code and has a good chance of revealing some minor typos, which have a huge impact on code correctness. Due to major changes in the amount of warnings that are enclosed by -Wall in the last few minor versions of gcc, we are a little behind producing a clean build with those versions. But in the end we should have a version of Irrlicht which shows no warnings with -Wall. It won't change your binary at least, as it only affects warning thresholds.
As I told you before, std=XX also is largely unproblematic. However, it also sets some strictness and some special defines. And the mingw headers are not properly working with those things defined in all cases. One such thing is that the _MAX_PATH is not defined, although it probably should be.
My last guess about your original problem is now, that you probably never got a newer library, only a newly compiled app. And due to major header changes, both used a different layout for the IVideoDriver structure. Which easily leads to a crash due to illegal memory usage. Still, nothing in the engine, just a problem with your build environment.
In case you can fix some of the warnings you can suggest patches to reduce the amount of warnings under -Wall.

[Cube_]

I'll look into them.
And "My last guess about your original problem is now, that you probably never got a newer library, only a newly compiled app."
Not exactly, I got a 1.8 library compiled with "some strictness and some special defines" which Irrlicht apparently didn't like.

Anyway, looking into the warnings now.
Also, no I don't have -Werror set, I hate that flag. *I double checked this*
My build env. might be a bit insane :/

[CuteAlien]

Hm, I remember having had some trouble with c::b in the past, but not sure about the flag. Maybe search for -W (it's same as -Wextra), also look in the defines section of the project build options. And then try removing that, maybe it helps. Maybe also remove -Wextra for testing. I'm not having the problem with C::B here right now, so not exactly sure what it is. But I remember there was once some discussion about a similar problem with codeblocks seeing warnings as errors on the forum - just can't find it right now.

[hendu]

Warnings will not halt the build unless you have -Werror, ever. Double-check your logs and actual build commands.

[Cube_]

Well, for some reason Code::Blocks treats Warnings with the structure
[Warning] Note:
[this part is treated like an error]
I don't actually know why, I will just consider that a bug in code::blocks

Anyway, the debug build still fails at the same place *Oh, and starting to get some of the warnings sorted out, well kind of*

[CuteAlien]

Did you try a clean rebuild? (I guess you did... but if not try it - sometimes even compilers mess up).

[Cube_]

Yes, yes I did. If something fails after a failed build I always try a clean build just to be sure.

[CuteAlien]

It seems code::blocks finds the information if something is a warning or an error by parsing the text-output from gcc. But as you have english warnings it's strange this fails (happens to some people working with other languages), still just in case you can try the following:

Use the envvar-plugin to set "LC_ALL" to "en_US.UTF-8" ("Settings.. -> Environment -> Environment variables").

[Cube_]

Will try it next time (Silly code::blocks)