You're saying that the gcc float.h overrides the mingw one. Yes that does make sense.
Also yes sending it to GCC makes sense.
I'm not sure why you define the _NEXT_FLOAT_H_ macro though.
Your proposed use of __MINGW32__ looks right. __MINGW32__ is indeed defined by both {arm,i386}-mingw32ce-gcc . arm-cegcc-gcc doesn't appear to have this situation and it doesn't define __MINGW32__.
The output is different on my Linux box. The last element of "libraries" does evaluate to the right place for me (/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/../../../../arm-mingw32ce/lib/ -> /opt/mingw32ce/arm-mingw32ce/lib/crt3.o) .
Does someone with a cygwin system know what's wrong ?.
Defining it as a macro that expands to the well known x86 pseudo-instruction does make sense.
I will do that.
For the record :
- that's not the same thing as having it exported from coredll
- I don't want to copy a definition from Visual C++ : that would violate copyrights.
Thanks for the input.
