Doesn't compile without modification on Mingw (but does compile! :-) )

[GoogleCodeExporter]

Stb-imv does not compile without modifying the source on the free MingW
toolchain. Luckily, the modifications needed are fairly minor.

in stb.h:
- disabled using the assembly version of stb_log_floor
- typedef unsigned __int64 stb__64; (instead of _int64)
- commented out the redefinition of CreateSemaphoreA
- removed the stb_barrier functionality. (This probably isn't safe, right?)
in stb_image.c:
- made the uint8, etc typedefs #defines instead.
- removed validate_uint32
- changed the last line to #endif (instead of #endif STBI_NO_WRITE)
in imv.c:
- removed the memory barrier (again, unsafe?)
- moved "int temp = max_cache_bytes >> 20;" out of the if() statement
- made rom_images not extern.
- disabled using the MMX assembly interpolation functions (#if 1 -> #if 0)

And compiled with gcc -o stbimv.exe imv.c -lgdi32 -luser32 -lcomdlg32
-lole32 -D_MT

Tested using Windows XP, gcc version 3.4.2 (mingw-special).

Hope this helps somehow! :)

Original issue reported on code.google.com by the...@gmail.com on 30 Nov 2007 at 8:27

[GoogleCodeExporter]

Hi, I'll look into some of these changes.

Is there a standard MinGW #define I can check for to #ifdef with?

Some specific points:
- CreateSemaphoreA: I'm surprised this didn't cause problems with other 
versions of
MSVC, actually
- The uint8 stuff is bizarre. Is MinGW defining them itself? That seems like it 
would
break ten million programs.
- The "#endif STBI_NO_WRITE" stuff is totally a bug, it's supposed to be 
"#endif //
STBI_NO_WRITE", but apparently VC6 doesn't complaint about it.
- I don't understand why you'd make rom_images not extern. Then again, your 
command
line doesn't include pics.c, so maybe you #included it or concatenated it to 
imv.c
instead?
- I don't understand why you had to move the definition of 'int temp'. What was 
the
error as it was?

And yes, the lack of the stb_barrier() is probably going to introduce race 
conditions
which is going to lead to random crashes, hangs, or misbehaviors of some kind. I
think there's a standard windows barrier I can call instead--it's not available 
in
MSVC6 which is why I did it the way I did, but probably you're using more recent
windows headers with mingw anyway.

Original comment by nothings...@gmail.com on 30 Nov 2007 at 8:43

• Added labels: Type-Enhancement
• Removed labels: Type-Defect