Bugs (deprecated, use Trac) item #2896500, was opened at 2009-11-12 01:35 Message generated for change (Settings changed) made by pfalcon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2896500&group_id=173455
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Ivan Maidanski (ivmai) Assigned to: Danny Backx (dannybackx) Summary: Patch for GCC float.h Initial Comment: Without this patch, I have to set c_include_path=/cygdrive/C/x86mingw32ce/i386-mingw32ce/include. The same problem exists in mingw-w64 project, see: https://sourceforge.net/tracker/index.php?func=detail&aid=2363741&group_id= 202880&atid=983354 The patch should be really sent to GCC but I'd like to know your opinion. I use __MINGW32__ to identify toolchains that have MS-specific float.h (i.e., for CeGCC toolchains, they are mingw32ce and x86mingw32ce but not cegcc). Should be correct, right? ---------------------------------------------------------------------- Comment By: Ivan Maidanski (ivmai) Date: 2009-11-14 08:33 Message: > Also yes sending it to GCC makes sense. Unfortunately, it seems it doesn't... See this post: https://sourceforge.net/tracker/?func=detail&aid=2896485&group_id=202880&atid=983356 This post also suggests another solution - copy the contents of gcc float.h into the specific mingw one and remove the gcc one. > I'm not sure why you define the _NEXT_FLOAT_H_ macro though. This is just a guard against infinite recursion between a specific float.h and a gcc one (they may both do include_next each other (before checking for _FLOAT_H) in some toolchains). _NEXT_FLOAT_H_ is not used anywhere else (and is unique as reported by google codesearch). ---------------------------------------------------------------------- Comment By: Danny Backx (dannybackx) Date: 2009-11-13 23:22 Message: 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__. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2896500&group_id=173455 ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
