Menu
▾
▴
[MinGW-notify] [ mingw-Bugs-3441135 ] LDBL_MIN_EXP and LDBL_MAX_EXP undefined
|
From: SF/projects/mingw n. l. <min...@li...> - 2011-11-29 13:26:04
|
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-29 05:26 Message: Re: BTW It was top_builddir, I must have had a brain lapse. The option works smoothly. I wonder if we should allow for w32api.old and/or w32api.bak to not be automatically assumed? Maybe a later option. Now on to https://sourceforge.net/tracker/?func=detail&aid=3443215&group_id=2435&atid=102435 so we can use the newly built mingwrt. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-11-28 13:39 Message: Arrrrrgh! I missed a slash after ${top_builddir}. Please try the updated patch attached; you'll need to revert the previous one first, or just make the manual adjustment in aclocal.m4). BTW, are you sure it was S["W32API_INCLUDE"]=${top_srcdir}...? I expected S["W32API_INCLUDE"]=${top_builddir}..., and indeed, that's what I see when I try to reproduce your failure case. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2011-11-28 13:07 Message: The patch failed for --with-w32api-source=../bak.w32.api in that -I is specified as .../bak.w32.api when S["W32API_INCLUDE"]=${top_srcdir}../bak.w32.api is given in config.status. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-11-28 07:50 Message: For clarification, the fall back path search is restricted to those directories satisfying a file name match for ${top_srcdir}/../w32api*/include/windows.h ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-11-28 07:32 Message: I've attached a patch, adding a --with-w32api-srcdir=DIR option to configure, with properly documented inclusion in 'configure --help'; it allows the user to explicitly specify a path to the ${top_srcdir} of the w32api source tree. If the user does supply such a path, it performs a sanity check, requiring windows.h to exist, as a file, at ${with_w32api_srcdir}/include/windows.h If the user does not specify such a path, fall back action is to search for the first subdirectory of ${top_srcdir}/.. -- i.e. mingwrt's ${top_srcdir}/.. -- in which an include/windows.h file is found; this is then assigned to ${with_w32api_srcdir} In either scenario, if the check for ${with_w32api_srcdir}/include/windows.h fails, then configure will abort immediately, with suitable diagnostics; otherwise, W32API_INCLUDE is defined as ${with_w32api_srcdir}/include -- with reference resolution via ${top_srcdir} or ${top_builddir} if appropriate -- and AC_SUBSTed to all dependent Makefiles, with -I flag affixed. It seems to work for me, automatically mapping W32API_INCLUDE for my 'mingw-get source ...' derived tree, to: W32API_INCLUDE = -I ${top_srcdir}/../w32api-3.17-2-mingw32/include (which is correct), allowing me to build successfully without creating any symlinks. Please test, to confirm that it also works correctly for you. You will need to apply the patch, then run autoconf to regenerate the configure script itself. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-11-27 06:54 Message: Ah ha! So, now we're getting to a more pragmatic view of the issue. It appears that, although our symptoms appeared to differ, they were related to the same cause; in configure.in: AC_SUBST([W32API_INCLUDE], ['-I ${top_srcdir}/../w32api/include']) isn't sufficient, given that our source tarballs, as delivered by 'mingw-get source mingwrt w32api', would actually require: AC_SUBST([W32API_INCLUDE], ['-I ${top_srcdir}/../w32api-<version>-mingw32/include']) and that <version> tag makes this non-deterministic. In my case, I was able to work around the issue by creating a symbolic link, the the working directory where I ran 'mingw-get source ...', from w32api-<version>-mingw32 to w32api, but that isn't a generally acceptable solution for the MSW platform; I agree that we need a more generalised AC_ARG_WITH type solution, implemented within the configure script. BTW, autoconf's GCS driven semantic rules demand that the option be '--with-something', and for stylistic consistency I propose '--with-w32api-srcdir=DIR' for this case. I'll give some thought to a suitable AC_ARG_WITH implementation to add it -- it will be AC_ARG_WITH([w32api-srcdir],...), with code to evaluate it, and culminating in the appropriate AC_SUBST([W32API_INCLUDE],...) definition. I'd also like to point out that autoconf deprecated 'configure.in', as its input file name, several years ago; perhaps we should consider adopting the currently preferred 'configure.ac' name, when we implement this change. Perhaps we should also consider this as a good opportunity for addressing the myriad FIXME's, (many of which are my additions), throughout 'configure.in' and 'Makefile.in'. ---------------------------------------------------------------------- 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 |