From: SF/projects/mingw n. l. <min...@li...> - 2011-11-26 23:52:37
|
Bugs item #3441135, was opened at 2011-11-22 07:00 Message generated for change (Comment added) made by earnie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3441135&group_id=2435 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: None Priority: 5 Private: No Submitted By: Earnie Boyd (earnie) Assigned to: Chris Sutcliffe (ir0nh34d) Summary: LDBL_MIN_EXP and LDBL_MAX_EXP undefined Initial Comment: I just downloaded the source package for mingwrt-3.20 and was executing configure && make when the compiler vomited out that LDBL_MAX_EXP and LDBL_MIN_EXP were not defined. Should they be defined in float.h? What values? ---------------------------------------------------------------------- >Comment By: Earnie Boyd (earnie) Date: 2011-11-26 15:52 Message: Hmmmmmmmmm So I had been mucking W32API_INCLUDE to add -I/mingw/include after the top_srcdir and that is what caused the difference. Putting the source for w32api in the parent for mingwrt allowed the build to complete. So what we need is a patch to configure to abort if the source w32api directory cannot be found with an appropriate message and maybe allow the user to --w32api_source=<DIR>. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-11-25 14:40 Message: But is the patch needed? Is any patch needed? I'm mystified. I just rebuilt mingwrt from my own CVS sandbox, and I can't reproduce this, (or indeed any), build failure. I then did: mingw-get source mingwrt w32api and repeated the build exercise. This time, it wasn't problem free, but the problems were completely unrelated to the scope of this ticket. I simply cannot reproduce this issue, and I'm opposed to applying patches without a thorough understanding of the issue which necessitates them. FWIW, the issues I did encounter were that, in neither of the respective source tarballs, are the configure scripts, nor their config.{sub.guess} helpers, marked with the executable attribute, (as they should be), and that the w32api tarball names its $top_srcdir as w32api-<version>-mingw32, but the mingwrt build system requires it to be named simply w32api. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2011-11-25 10:20 Message: The patch I've given doesn't override the ones supplied by GCC. Only defines what is needed if include_next fails. I've tried multiple combinations of things but I don't remember if I tried -isystem. I'll give it a try and report back. But remember -nostdinc is also given how does that affect -isystem? ---------------------------------------------------------------------- Comment By: Chris Sutcliffe (ir0nh34d) Date: 2011-11-23 11:45 Message: It feels wrong to me to override a value defined in a gcc system header. What about using one of gcc's command line options to set header order instead? Something like: --isystem =/include see http://gcc.gnu.org/onlinedocs/cpp/Invocation.html#Invocation for more details. I realize this does not fix the issue, but is a workaround that could be used. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2011-11-23 11:08 Message: Maybe this? It allows mingwrt to build. For some reason the include_next doesn't find the GCC version of float.h when building mingwrt but under normal circumstances it is. I don't know about the value for LDBL_MAX_EXP/LDBL_MIN_EXP but I found one reference that set it to 999/-999 respectfully. GCC must set it to 16384 based on my printf test for LDBL_MAX_EXP. diff --git a/include/float.h b/include/float.h index 47017c9..2a5126a 100644 --- a/include/float.h +++ b/include/float.h @@ -36,6 +36,12 @@ * */ # include_next <float.h> +# ifndef FLT_RADIX +# define DBL_DIG 16 +# define FLT_RADIX 10 +# define LDBL_MAX_EXP (FLT_RADIX * 100) - 1 +# define LDBL_MIN_EXP LDBL_MAX_EXP * -1 +# endif #endif /* All the headers include this file. */ ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2011-11-22 11:49 Message: Seems like moving/removing include_next and defining our own would be best? ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-11-22 08:50 Message: There's been a long standing issue regarding float.h. Danny's builds of gcc-3.x always scheduled the mingwrt float.h BEFORE gcc's own; just about everyone else's, (including my own cross-compiler build), did it the other way round. mingwrt's float.h uses include_next to pull in gcc's version, but IIRC gcc's has never extended the courtesy in the reverse direction. -nostdinc may exacerbate the issue, but the issue remains regardless. I don't know how to fix it, but a fix is badly needed; it seems likely that it will require more than just local changes within mingwrt. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2011-11-22 07:09 Message: Hmm, so the issue is, GCC's float.h was not found in the include_next statement. Maybe due to -nostdinc? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3441135&group_id=2435 |