Can't Use DUMB_OFF_T_CUSTOM to Fix Static Assertion On 32-Bit System

[kode54]

Can't Use DUMB_OFF_T_CUSTOM to Fix Static Assertion On 32-Bit System

[kode54]

Aww, crap, how could have missed that? Fixed by e9320b6.

[kode54]

Some 2.0.0 this has turned out to be.

[SimonN]

I had read the line several times, too, but didn't notice it either. >_>; Thanks for the quick fix.

Maybe bump header & tag as 2.0.1? The 2.0.0 blocked an Allegro 5 build on Ubuntu -- but it may well be an Allegro issue: We're already considering in A5 to define _FILE_OFFSET_BITS instead of supplying DUMB_OFF_T_CUSTOM.

[Rondom]

Good catch. I will fix this. What is your use case for defining this manually? On what platform are you compiling on? I am asking, because the checks in the header should actually catch all "common" platforms i.e. Linux (and other Unices), MinGW-W64, MSVC, DJGPP.

[Rondom]

Sorry, still not fully awake. I agree that, if possible, one should define -D_FILE_OFFSET_BITS=64 or define it manually in the code if your whole codebase is not ready for this for some reason. As @SimonN said, that's the path that Allegro5 is likely going to take.

And yes, pushing a 2.0.1 out, does not hurt.

[NewCreature]

What is your use case for defining this manually?

I am trying to build Allegro 5 on a 32-bit Ubuntu machine. The auto-detect code gives me a 32-bit type, which causes building Allegro 5 to fail on the static assertion where it includes 'dumb.h'. I just tried that option since it seemed like the quickest way to get Allegro to compile so I could get back to my project.

[Rondom]

As written above this can be closed because it has been fixed with e9320b6