[fixed]mingw gcc 4.7

[sudi]

When using gcc 4.7 to build irrlicht and its demos it isn't able to load the default font any more. i do not know why but it simply can't do it. The bmp loader complaints about about compression. This bug is there in the newest svn and irrlicht 1.7.3

[CuteAlien]

Thanks for reporting. Unfortunately I'm somewhat scared of figuring out how to update gcc in MinGW to a new version... there's like a million lzma files + dependencies *sigh*.

You just got it running, so before I mess up my system now completely (wouldn't be first time with MinGW) - do you accidentally still know which files have to be installed for a clean update?

[sudi]

Well CuteAlien its actually pretty simple to set up. Check http://www.mingw.org/wiki/Getting_Started just use "mingw-get install gcc" or in case you already have all that setup use "mingw-get upgrade". But to be honest i have no idea how to downgrade back to 4.6.

[CuteAlien]

Thanks, I didn't know about mingw-get upgrade (I used graphical installer last time, tried using that again but it seemed to want to reinstall everything, so I didn't risk continuing).

I can reproduce it - example 01 has no longer a texture. Also have another problem in combination with C::B right now (can no longer stop debugging and have to restart C::B on each run), I'll try if I can figure out something.

[CuteAlien]

Ok, as workaround for now compile Irrlicht with: -mno-ms-bitfields
I might add that flag later on, but still trying to figure out why that is needed now. Especially as it sounds rather wrong, as that flags usually should lead to a packing different from the one by MS compilers, while in reality this seems to the only way to get the same behaviour now. Also that struct doesn't even use a bitfield - how gcc get's the size there wrong now is completely confusing. My current guess is gcc-4.7 on mingw messed up big time, but likely I'll be proven wrong once I understand the real reason or so.

[hendu]

Which struct?

As for why, 4.7 made that the default. Saves everyone from having to manually input it, as usually everyone on mingw wants that option.

[CuteAlien]

The problem is not that option but that it doesn't really do the expected thing. I just posted the following example to the mingw mailinglist, I hope they have some hints. But posting it here as well in case someone got an idea:

Code: Select all

 
// The struct "Header" is not using bitfields, but still when compiled with
// -m-ms-bitfields (which is now the new default) it will be larger than with
// -mno-ms-bitfields.
// I get _different_ results from compiling with Microsoft Compiler and packing when using -m-ms-bitfields
// I get _identical_ results when compiling with -mno-ms-bitfields.
 
#include <cstdio>
 
#if defined(_MSC_VER)
#pragma pack( push, packing )
#pragma pack( 1 )
#endif
 
struct Header
{
        unsigned char IdLength;
        unsigned char ColorMapType;
        unsigned char ImageType;
        unsigned char FirstEntryIndex[2];
        unsigned short ColorMapLength;
        unsigned char ColorMapEntrySize;
        unsigned char XOrigin[2];
        unsigned char YOrigin[2];
        unsigned short ImageWidth;
}
#if defined(__GNUC__)
__attribute__((packed))
#endif
;
 
#if defined(_MSC_VER)
#pragma pack( pop, packing )
#endif
 
int main ()
{
        printf("sizeof(Header): %d\n", sizeof(Header));
        return 0;
}
 

Results for the size are:
With VS 2010 (32 bit as well as 64-bit): 14
Compiled with gcc 4.7 and -mno-ms-bitfields: 14
gcc 4.7 and new default (or with -mms-bitfields explicitly): 16


So basically the problem is that it a) affects packing when it shouldn't and b) the flag seems to make the difference to the Microsoft compiler (and to gcc 4.6) larger instead of smaller. But maybe I'm just missing something.

[sudi]

Thanks alot. I almost thought i have to stick with 4.6 for irrlicht.

[hendu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991

Maybe related.

[hybrid]

Yeah, that was also the example we found and from where I finally got to the ms-bitfields parameter. However, this bug is also not yet considered to the end.

[CuteAlien]

Found a bugtracker entry for that and added my example: https://sourceforge.net/tracker/index.p ... tid=983354

There is a remark that: "__attribute__ ((__packed)) applies only to last field of struct." and "Trick is here '#pragma pack(1)'."
Which I consider as being very strange, but I guess we can add #pragma pack(1) for mingw gcc versions >= 4.7 and we should be fine without breaking anything (I just have to figure out defines to use for that, will do later on or next week if I don't find time today).

[CuteAlien]

Trunk works now (r4226) again with gcc 4.7 on MinGW. I hope I broke no other gcc compiles, will test on Linux later on.