[ mingw-Bugs-3441135 ] LDBL_MIN_EXP and LDBL_MAX_EXP undefined

This list is used to send updates of submitted patches, bug reports and file releases.  You are discouraged
from posting to this list.  If you wish to unsubscribe you can do so at https://lists.sourceforge.net/lists/listinfo/mingw-notify.
Bugs item #3441135, was opened at 2011-11-22 07:00
Message generated for change (Comment added) made by keithmarshall
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: Keith Marshall (keithmarshall)
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: Keith Marshall (keithmarshall)
Date: 2012-08-06 13:24

Message:
It appears that we didn't; I'll follow up.

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2012-08-04 11:24

Message:
Ping, Keith, did we ever get this patch applied?

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2012-01-01 23:59

Message:
Mike,

I do know that directories specified with -I are scanned before those
specified with -isystem, EXCEPT when the SAME PATH is specified with both. 
Your statement is a direct contradiction of the GCC manual; see:
http://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html#Directory-Options

In particular, the first sentence of the second paragraph under the -Idir
sub-heading:
| If a standard system include directory, or a directory
| specified with -isystem, is also specified with -I,
| the -I option will be ignored.

In this sense,the effect of -isystem overrides the effect of -I, for the
path specified with both, so unless the manual is wrong, I stand by my
previous statement.

Thanks for the cacert pointer, BTW.

----------------------------------------------------------------------

Comment By: Mike Frysinger (vapier)
Date: 2012-01-01 23:11

Message:
i don't know if you misspoke, or have an incorrect idea in your mind, but
-isystem does not override -I.  it's the other way around.  the gcc search
order for headers: -I then -isystem then the compiled in system paths (if
-nostdlib/etc... are not specified).  and yes, there are a few more
nuances, but for illustration here i don't think i need to get into them.

you are correct in that specifying both makes no sense.

as for firefox/Gentoo, you need to install the cacert root cert from
http://cacert.org/.  firefox gives you that warning for all ssl certs it
doesn't know about.  click this link: http://www.cacert.org/certs/root.crt

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2011-12-28 01:47

Message:
Thanks for the heads-up.

I don't understand why adding $(W32API_INCLUDE) a second time, with
-isystem rather than -I should make the slightest difference, unless it's
papering over the cracks of some fundamental inconsistency in the headers
-- AIUI, system headers attract a lesser degree of consistency checking,
because they are deemed to have been rigorously tested beforehand.  If this
is the case, then we aren't interested in this work around -- we want to
fix the underlying problem instead.

Your modified patch has:
  -isystem $(W32API_INCLUDE) -I $(W32API_INCLUDE)

That definitely isn't necessary.  It may be harmless, but the second
reference is superfluous; -isystem overrides -I, so gcc should simply
ignore the latter.

Sorry, but without a detailed technical justification, and detailed
instructions for reproducing the problem -- it WJFFM -- I deem this to be
an unnecessary kludge, which I will not be adopting.

BTW, Firefox tells me your Gentoo bug site is not trustworthy.

----------------------------------------------------------------------

Comment By: Matthias Dahl (matt2000)
Date: 2011-12-24 05:52

Message:
Unfortunately I cannot attach any files to this bug, so here the link to my
Gentoo bug which has everything attached:

https://bugs.gentoo.org/show_bug.cgi?id=395893

----------------------------------------------------------------------

Comment By: Matthias Dahl (matt2000)
Date: 2011-12-24 05:39

Message:
Unfortunately even after several changes and tries, I wasn't able to
compile mingwrt-3.20 successfully. I revised the proposed patch slightly by
included an appropriate isystem include to the w32api. After that,
everything went smoothly actually. Hope this helps.

Merry Christmas everyone btw. 

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2011-11-30 08:29

Message:
Scratch my comment.  What you say is true.  I was confused by your earlier
comment of Date: 2011-11-28 13:39:51 PST.  The -2 patch is good.

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2011-11-30 08:08

Message:
RE: top_builddir versus top_srcdir.

I don't understand your point.  What do you see, when you run configure? 
(Look, in particular, for the line beginning "checking include path for
w32api headers ...").

If you don't specify --with-w32api-srcdir, and assuming you actually have a
w32api source tree in place, then you should see:
"${top_srcdir}/../w32api...".  Isn't that exactly what you're asking for? 
If not, then what do you want to see?  IMO, anything else would be utterly
wrong.

OTOH, if you do specify --with-w32api-srcdir, then there are three
plausible cases:

1) You specify an absolute path.  Provided you specified it correctly,
that's exactly where configure will look, and whatever absolute path you
specify will be passed into Makefile, verbatim.

2) You build "in-source", and specify a relative path; in this case
${top_srcdir} and ${top_builddir} refer to identically the same directory,
so the issue is moot.  Makefile will inherit a reference via
${top_builddir}, which will be resolved just the same as if it had been
specified relative to ${top_srcdir} instead.

3) You build "out-of-tree", specifying a relative path.  In this case.
${top_builddir} refers to your current working directory when you run
configure, and ${top_srcdir} refers to a different directory, (normally a
relative path to where the top of the source tree is to be found).  In this
case, I contend that it is illogical to specify a relative path to an
external source tree, which is relative to anything other than current
working directory; (think of shell tab completion to specify it); hence
IMO, ${top_builddir} is the correct reference for this case.

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2011-11-30 06:41

Message:
RE: top_builddir versus top_srcdir.

The original work used top_srcdir and I think it should carry forward that
way.  If I build in a child directory of the mingwrt source then it should
look in ${top_srcdir}/../ for w32api.

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2011-11-29 07:53

Message:
> I wonder if we should allow for w32api.old and/or
> w32api.bak to not be automatically assumed?

Well, now your proposing heuristic choices, which certainly isn't elegant,
and may not be desirable; I don't know if he has a legitimate claim to
being the original author, but I first saw this in a message from Bruno
Haible:

"Any algorithm having a heuristic basis is broken, by design".

> Maybe a later option.

It certainly wouldn't be a difficult addition, but is it desirable?  I'd
like to see opinions from the other active developers before just jumping
in; maybe consider escalating the discussion to mingw-dvlpr?

----------------------------------------------------------------------

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
 <at>  <at>  -36,6 +36,12  <at>  <at> 
   *
   */
 # 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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/