SDLDevil 0.5 released!

[Kp]

Fixing the SConstruct file to account for this would have saved me a few hours of frustration.

To whom are you speaking?  This is a thread about SDLDevil, which does not use SConstruct.  If you are looking at Rebirth, which does use SConstruct, then I fixed this last August in Fix level load hang on >=mingw32-gcc-4.7.

[Edit: fixed link.]

[spud]

Your comment was about rebirth, which I was also referring to. That commit link gives me a 404, but I'll take your word for it.  A search for bitfields (https://github.com/dxx-rebirth/dxx-rebir...q=bitfield) returns nothing, maybe you didn't fix it using the -mno-ms-bitfields flag?

I was trying to build the 58.1 sources with mingw32-gcc 4.8.2, and couldn't load player files due to the structure packing issues; compiler bugs are pretty frustrating.

[Kp]

Sorry, a copy error dropped the leading digit from the commit ID I tried to paste.  The link is fixed now.

That search is not very good.  The log message of the linked commit is:

    Fix level load hang on >=mingw32-gcc-4.7
   
    Starting in gcc 4.7 "Windows mingw targets are using the -mms-bitfields
    option by default." <http://gcc.gnu.org/gcc-4.7/changes.html>.  This
    causes __attribute__((packed)) not to be effective on structures that
    are used to express the layout of on-disk data.  In turn, that causes
    piggy.c to mishandle texture loads, eventually resulting in an infinite
    loop.  Add a pragma pack to force the headers to pack tightly on
    Windows.

As you can see, it references bitfields, so the search should have found it.

I fixed it using a #pragma directive, rather than a compiler option.

[spud]

I fixed it using a #pragma directive, rather than a compiler option.

Nice, that's a much better way of dealing with the problem, thanks!