SDLDevil 0.5 released!
#31
(05-29-2014, 03:57 PM)spud link Wrote: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.]
Reply
#32
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.
Reply
#33
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:
Quote:    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.
Reply
#34
(05-31-2014, 12:42 AM)Kp link Wrote: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!
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)