unexmacosx.c and limits.h problem

unexmacosx.c and limits.h problem

[Bob Halley]

Note that I build with -with-wide-int in my ./configure, which is likely relevant here.

The recent changes to generate limits.h on the master branch run because my platform (MacOS Sierra) does not define things like ULLONG_WIDTH).

Most of the C source compiles, but unexmacosx.c fails with:

In file included from unexmacosx.c:100:
./lisp.h:93:26: error: use of undeclared identifier 'LLONG_WIDTH'
enum { EMACS_INT_WIDTH = LLONG_WIDTH };
                         ^
./lisp.h:119:29: error: use of undeclared identifier 'SIZE_WIDTH'
enum { BITS_PER_BITS_WORD = SIZE_WIDTH };
                            ^

And a bunch more related errors, all because those limits.h constants are not defined.

Analysis reveals that while the generated ../lib/limits.h is indeed read, it does NOT define LLONG_WIDTH, etc.  The reason for this is that

#if (! defined ULLONG_WIDTH                                             \
     && (defined _GNU_SOURCE || defined __STDC_WANT_IEC_60559_BFP_EXT__))

is false, because neither _GNU_SOURCE nor  __STDC_WANT_IEC_60559_BFP_EXT__ are defined.

The reason other code works is because it #include <config.h> which defines it before including <limits.h>, but unexmacosx.c includes <stdlib.h> before including <config.h> for reasons it describes, and this causes <limits.h> to get included as well.

My fix was:

diff --git a/src/unexmacosx.c b/src/unexmacosx.c
index bdacc8b..4dd35fb 100644
--- a/src/unexmacosx.c
+++ b/src/unexmacosx.c
@@ -90,6 +90,9 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
    with the #define:s in place, the prototypes will be wrong and we get
    warnings.  To prevent that, include stdlib.h before config.h.  */
 
+#ifndef _GNU_SOURCE
+#define _GNU_SOURCE 1
+#endif
 #include <stdlib.h>
 #include <config.h>
 #undef malloc

Regards,

/Bob

Re: unexmacosx.c and limits.h problem

[Paul Eggert]

On 09/16/2016 04:04 PM, Bob Halley wrote:
> +#ifndef _GNU_SOURCE
> +#define _GNU_SOURCE 1
> +#endif

Thanks, I installed that into Emacs master.

Re: unexmacosx.c and limits.h problem

[Richard Copley]

On 17 September 2016 at 02:02, Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 09/16/2016 04:04 PM, Bob Halley wrote:
>>
>> +#ifndef _GNU_SOURCE
>> +#define _GNU_SOURCE 1
>> +#endif
>
>
> Thanks, I installed that into Emacs master.

The Windows build is broken too (with MSYS2), presumably for a similar
reason. Adding those same three preprocessor directives before the
includes of <stdlib.h> in "w32.c" and "w32_proc.c" is enough to let
the build succeed.

Re: unexmacosx.c and limits.h problem

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Sat, 17 Sep 2016 12:03:14 +0100
> Cc: Bob Halley <halley@play-bow.org>, Emacs Development <emacs-devel@gnu.org>
> 
> On 17 September 2016 at 02:02, Paul Eggert <eggert@cs.ucla.edu> wrote:
> > On 09/16/2016 04:04 PM, Bob Halley wrote:
> >>
> >> +#ifndef _GNU_SOURCE
> >> +#define _GNU_SOURCE 1
> >> +#endif
> >
> >
> > Thanks, I installed that into Emacs master.
> 
> The Windows build is broken too (with MSYS2), presumably for a similar
> reason.

It isn't broken here.  Can you show the error messages?

Re: unexmacosx.c and limits.h problem

[Richard Copley]

On 17 September 2016 at 12:18, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Sat, 17 Sep 2016 12:03:14 +0100
>> Cc: Bob Halley <halley@play-bow.org>, Emacs Development <emacs-devel@gnu.org>
>>
>> On 17 September 2016 at 02:02, Paul Eggert <eggert@cs.ucla.edu> wrote:
>> > On 09/16/2016 04:04 PM, Bob Halley wrote:
>> >>
>> >> +#ifndef _GNU_SOURCE
>> >> +#define _GNU_SOURCE 1
>> >> +#endif
>> >
>> >
>> > Thanks, I installed that into Emacs master.
>>
>> The Windows build is broken too (with MSYS2), presumably for a similar
>> reason.
>
> It isn't broken here.  Can you show the error messages?

Sure, give me a few minutes. Did you reconfigure? You need the
generated limits.h.

Re: unexmacosx.c and limits.h problem

[Richard Copley]

On 17 September 2016 at 12:28, Richard Copley <rcopley@gmail.com> wrote:
> On 17 September 2016 at 12:18, Eli Zaretskii <eliz@gnu.org> wrote:
>>> From: Richard Copley <rcopley@gmail.com>
>>> Date: Sat, 17 Sep 2016 12:03:14 +0100
>>> Cc: Bob Halley <halley@play-bow.org>, Emacs Development <emacs-devel@gnu.org>
>>>
>>> On 17 September 2016 at 02:02, Paul Eggert <eggert@cs.ucla.edu> wrote:
>>> > On 09/16/2016 04:04 PM, Bob Halley wrote:
>>> >>
>>> >> +#ifndef _GNU_SOURCE
>>> >> +#define _GNU_SOURCE 1
>>> >> +#endif
>>> >
>>> >
>>> > Thanks, I installed that into Emacs master.
>>>
>>> The Windows build is broken too (with MSYS2), presumably for a similar
>>> reason.
>>
>> It isn't broken here.  Can you show the error messages?
>
> Sure, give me a few minutes. Did you reconfigure? You need the
> generated limits.h.

Also, this is with 64-bit GCC 6.1.0.

In file included from G:/emacs/repo/emacs/src/w32.c:87:0:
G:/emacs/repo/emacs/src/lisp.h:93:26: error: 'LLONG_WIDTH' undeclared
here (not in a function)
 enum { EMACS_INT_WIDTH = LLONG_WIDTH };
                          ^~~~~~~~~~~

In file included from G:/emacs/repo/emacs/src/w32proc.c:54:0:
G:/emacs/repo/emacs/src/lisp.h:93:26: error: 'LLONG_WIDTH' undeclared
here (not in a function)
 enum { EMACS_INT_WIDTH = LLONG_WIDTH };
                          ^~~~~~~~~~~

Re: unexmacosx.c and limits.h problem

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Sat, 17 Sep 2016 12:31:36 +0100
> Cc: Paul Eggert <eggert@cs.ucla.edu>, Bob Halley <halley@play-bow.org>, 
> 	Emacs Development <emacs-devel@gnu.org>
> 
> >>> >> +#ifndef _GNU_SOURCE
> >>> >> +#define _GNU_SOURCE 1
> >>> >> +#endif
> >>> >
> >>> >
> >>> > Thanks, I installed that into Emacs master.
> >>>
> >>> The Windows build is broken too (with MSYS2), presumably for a similar
> >>> reason.
> >>
> >> It isn't broken here.  Can you show the error messages?
> >
> > Sure, give me a few minutes. Did you reconfigure? You need the
> > generated limits.h.
> 
> Also, this is with 64-bit GCC 6.1.0.
> 
> In file included from G:/emacs/repo/emacs/src/w32.c:87:0:
> G:/emacs/repo/emacs/src/lisp.h:93:26: error: 'LLONG_WIDTH' undeclared
> here (not in a function)
>  enum { EMACS_INT_WIDTH = LLONG_WIDTH };
>                           ^~~~~~~~~~~
> 
> In file included from G:/emacs/repo/emacs/src/w32proc.c:54:0:
> G:/emacs/repo/emacs/src/lisp.h:93:26: error: 'LLONG_WIDTH' undeclared
> here (not in a function)
>  enum { EMACS_INT_WIDTH = LLONG_WIDTH };
>                           ^~~~~~~~~~~

I don't understand how this could happen.  Take w32proc.c, for
example: it includes config.h _before_ lisp.h, and on my system
config.h has these:

  /* Enable GNU extensions on systems that have them.  */
  #ifndef _GNU_SOURCE
  # define _GNU_SOURCE 1
  #endif
  [...]
  /* Enable extensions specified by ISO/IEC TS 18661-1:2014.  */
  #ifndef __STDC_WANT_IEC_60559_BFP_EXT__
  # define __STDC_WANT_IEC_60559_BFP_EXT__ 1
  #endif

So by the time limits.h gets included (via lib/stdint.h, which is
included by nt/inc/stdint.h, which is included by nt/inc/ms-w32.h),
both _GNU_SOURCE and __STDC_WANT_IEC_60559_BFP_EXT__ are already
defined, and the definitions of LLONG_WIDTH in lib/limits.h should
have been processed.

Which part(s) of this don't work on your system, and why?

To find out what happens during preprocessing, I did this:

  cd src
  make w32proc.o -W w32proc.c V=1

Then I copied the command displayed by Make, replaced -c with -E,
appended "-o w32proc.ii", ran the command, and looked inside
w32proc.ii to see how the preprocessor included the various headers
and defined the macros.

(My GCC version is 5.3.0, and this is a 32-bit build with wide ints.)

Re: unexmacosx.c and limits.h problem

[Richard Copley]

On 17 September 2016 at 12:51, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Sat, 17 Sep 2016 12:31:36 +0100
>> Cc: Paul Eggert <eggert@cs.ucla.edu>, Bob Halley <halley@play-bow.org>,
>>       Emacs Development <emacs-devel@gnu.org>
>>
>> >>> >> +#ifndef _GNU_SOURCE
>> >>> >> +#define _GNU_SOURCE 1
>> >>> >> +#endif
>> >>> >
>> >>> >
>> >>> > Thanks, I installed that into Emacs master.
>> >>>
>> >>> The Windows build is broken too (with MSYS2), presumably for a similar
>> >>> reason.
>> >>
>> >> It isn't broken here.  Can you show the error messages?
>> >
>> > Sure, give me a few minutes. Did you reconfigure? You need the
>> > generated limits.h.
>>
>> Also, this is with 64-bit GCC 6.1.0.
>>
>> In file included from G:/emacs/repo/emacs/src/w32.c:87:0:
>> G:/emacs/repo/emacs/src/lisp.h:93:26: error: 'LLONG_WIDTH' undeclared
>> here (not in a function)
>>  enum { EMACS_INT_WIDTH = LLONG_WIDTH };
>>                           ^~~~~~~~~~~
>>
>> In file included from G:/emacs/repo/emacs/src/w32proc.c:54:0:
>> G:/emacs/repo/emacs/src/lisp.h:93:26: error: 'LLONG_WIDTH' undeclared
>> here (not in a function)
>>  enum { EMACS_INT_WIDTH = LLONG_WIDTH };
>>                           ^~~~~~~~~~~
>
> I don't understand how this could happen.  Take w32proc.c, for
> example: it includes config.h _before_ lisp.h, and on my system
> config.h has these:
>   /* Enable GNU extensions on systems that have them.  */
>   #ifndef _GNU_SOURCE
>   # define _GNU_SOURCE 1
>   #endif
>   [...]
>   /* Enable extensions specified by ISO/IEC TS 18661-1:2014.  */
>   #ifndef __STDC_WANT_IEC_60559_BFP_EXT__
>   # define __STDC_WANT_IEC_60559_BFP_EXT__ 1
>   #endif
>
> So by the time limits.h gets included (via lib/stdint.h, which is
> included by nt/inc/stdint.h, which is included by nt/inc/ms-w32.h),
> both _GNU_SOURCE and __STDC_WANT_IEC_60559_BFP_EXT__ are already
> defined, and the definitions of LLONG_WIDTH in lib/limits.h should
> have been processed.
>
> Which part(s) of this don't work on your system, and why?
>
> To find out what happens during preprocessing, I did this:
>
>   cd src
>   make w32proc.o -W w32proc.c V=1
>
> Then I copied the command displayed by Make, replaced -c with -E,
> appended "-o w32proc.ii", ran the command, and looked inside
> w32proc.ii to see how the preprocessor included the various headers
> and defined the macros.
>
> (My GCC version is 5.3.0, and this is a 32-bit build with wide ints.)

My preprocessed file doesn't show the #include or #define directives.
It sounds like yours does. Apparently another difference between our
toolchains. I obtained the preprocessed file the same way you did.

There are line/file preprocessor comments which probably contain
enough information to deduce what happened, but it's hard going.

I'll keep trying, unless you have any other tips?

I suppose the preprocessed source is no use to you, since you don't
have the same headers unless you update your MSYS, and if you do that
you won't need anything from me.

Re: unexmacosx.c and limits.h problem

[Richard Copley]

On 17 September 2016 at 13:28, Richard Copley <rcopley@gmail.com> wrote:
> On 17 September 2016 at 12:51, Eli Zaretskii <eliz@gnu.org> wrote:
>>> From: Richard Copley <rcopley@gmail.com>
>>> Date: Sat, 17 Sep 2016 12:31:36 +0100
>>> Cc: Paul Eggert <eggert@cs.ucla.edu>, Bob Halley <halley@play-bow.org>,
>>>       Emacs Development <emacs-devel@gnu.org>
>>>
>>> >>> >> +#ifndef _GNU_SOURCE
>>> >>> >> +#define _GNU_SOURCE 1
>>> >>> >> +#endif
>>> >>> >
>>> >>> >
>>> >>> > Thanks, I installed that into Emacs master.
>>> >>>
>>> >>> The Windows build is broken too (with MSYS2), presumably for a similar
>>> >>> reason.
>>> >>
>>> >> It isn't broken here.  Can you show the error messages?
>>> >
>>> > Sure, give me a few minutes. Did you reconfigure? You need the
>>> > generated limits.h.
>>>
>>> Also, this is with 64-bit GCC 6.1.0.
>>>
>>> In file included from G:/emacs/repo/emacs/src/w32.c:87:0:
>>> G:/emacs/repo/emacs/src/lisp.h:93:26: error: 'LLONG_WIDTH' undeclared
>>> here (not in a function)
>>>  enum { EMACS_INT_WIDTH = LLONG_WIDTH };
>>>                           ^~~~~~~~~~~
>>>
>>> In file included from G:/emacs/repo/emacs/src/w32proc.c:54:0:
>>> G:/emacs/repo/emacs/src/lisp.h:93:26: error: 'LLONG_WIDTH' undeclared
>>> here (not in a function)
>>>  enum { EMACS_INT_WIDTH = LLONG_WIDTH };
>>>                           ^~~~~~~~~~~
>>
>> I don't understand how this could happen.  Take w32proc.c, for
>> example: it includes config.h _before_ lisp.h, and on my system
>> config.h has these:
>>   /* Enable GNU extensions on systems that have them.  */
>>   #ifndef _GNU_SOURCE
>>   # define _GNU_SOURCE 1
>>   #endif
>>   [...]
>>   /* Enable extensions specified by ISO/IEC TS 18661-1:2014.  */
>>   #ifndef __STDC_WANT_IEC_60559_BFP_EXT__
>>   # define __STDC_WANT_IEC_60559_BFP_EXT__ 1
>>   #endif
>>
>> So by the time limits.h gets included (via lib/stdint.h, which is
>> included by nt/inc/stdint.h, which is included by nt/inc/ms-w32.h),
>> both _GNU_SOURCE and __STDC_WANT_IEC_60559_BFP_EXT__ are already
>> defined, and the definitions of LLONG_WIDTH in lib/limits.h should
>> have been processed.
>>
>> Which part(s) of this don't work on your system, and why?
>>
>> To find out what happens during preprocessing, I did this:
>>
>>   cd src
>>   make w32proc.o -W w32proc.c V=1
>>
>> Then I copied the command displayed by Make, replaced -c with -E,
>> appended "-o w32proc.ii", ran the command, and looked inside
>> w32proc.ii to see how the preprocessor included the various headers
>> and defined the macros.
>>
>> (My GCC version is 5.3.0, and this is a 32-bit build with wide ints.)
>
> My preprocessed file doesn't show the #include or #define directives.
> It sounds like yours does. Apparently another difference between our
> toolchains. I obtained the preprocessed file the same way you did.
>
> There are line/file preprocessor comments which probably contain
> enough information to deduce what happened, but it's hard going.
>
> I'll keep trying, unless you have any other tips?
>
> I suppose the preprocessed source is no use to you, since you don't
> have the same headers unless you update your MSYS, and if you do that
> you won't need anything from me.

I added an #error to limits.h; as you can see from the output below,
limits.h is already included via the system stdlib.h, which is
included near the top of w32proc.c, so the direct #include of limits.h
after config.h in w32proc.c has no effect.

In file included from
C:/msys64/mingw64/x86_64-w64-mingw32/include/stdlib.h:10:0,
                 from G:/emacs/repo/emacs/src/w32proc.c:27:
../lib/limits.h:21:2: error: #error limits
 #error limits
  ^~~~~

Re: unexmacosx.c and limits.h problem

[Richard Copley]

> I added an #error to limits.h; as you can see from the output below,
> limits.h is already included via the system stdlib.h, which is
> included near the top of w32proc.c, so the direct #include of limits.h
> after config.h in w32proc.c has no effect.
>
> In file included from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/stdlib.h:10:0,
>                  from G:/emacs/repo/emacs/src/w32proc.c:27:
> ../lib/limits.h:21:2: error: #error limits
>  #error limits
>   ^~~~~

This is similar to what Bob said in his original message,

> The reason other code works is because it #include <config.h> which
> defines it before including <limits.h>, but unexmacosx.c includes
> <stdlib.h> before > including <config.h> for reasons it describes,
> and this causes <limits.h> to get included as well.

Re: unexmacosx.c and limits.h problem

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Sat, 17 Sep 2016 13:56:03 +0100
> Cc: Paul Eggert <eggert@cs.ucla.edu>, Bob Halley <halley@play-bow.org>, 
> 	Emacs Development <emacs-devel@gnu.org>
> 
> > I added an #error to limits.h; as you can see from the output below,
> > limits.h is already included via the system stdlib.h, which is
> > included near the top of w32proc.c, so the direct #include of limits.h
> > after config.h in w32proc.c has no effect.
> >
> > In file included from
> > C:/msys64/mingw64/x86_64-w64-mingw32/include/stdlib.h:10:0,
> >                  from G:/emacs/repo/emacs/src/w32proc.c:27:
> > ../lib/limits.h:21:2: error: #error limits
> >  #error limits
> >   ^~~~~
> 
> This is similar to what Bob said in his original message,
> 
> > The reason other code works is because it #include <config.h> which
> > defines it before including <limits.h>, but unexmacosx.c includes
> > <stdlib.h> before > including <config.h> for reasons it describes,
> > and this causes <limits.h> to get included as well.

Which to me sounds like lib/limits.h is not a good place to define
these constants, or at least Emacs shouldn't rely on Gnulib's limits.h
to do its magic on all systems.

Paul?

Re: unexmacosx.c and limits.h problem

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]

Eli Zaretskii wrote:
> Which to me sounds like lib/limits.h is not a good place to define
> these constants, or at least Emacs shouldn't rely on Gnulib's limits.h
> to do its magic on all systems.

The ISO technical spec says the settings should go into <limits.h>, and if we 
put them somewhere else that will just make things more confusing in the long run.

I installed the attached patch, which should fix the immediate problem.

The fundamental problem here is that Emacs <config.h> over the years has bloated 
to contain many things that it should not. <config.h> should always be included 
first -- this is a key assumption of Autoconf and Gnulib -- and should contain 
only stuff that can appear in an included-first file. It should therefore not 
contain things like "#include <stdlib.h>" that can cause trouble in the cases 
we're talking about.

It's understandable why config.h has bloated, as it's a convenient catchall for 
stuff that has to be visible "everywhare" at the C level. The 
visibility-"everywhere" problem needs to be addressed in some other way, that's 
all. I'll look into fixing this.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Define-_GNU_SOURCE-in-files-delaying-config.h.patch --]
[-- Type: text/x-diff; name="0001-Define-_GNU_SOURCE-in-files-delaying-config.h.patch", Size: 2581 bytes --]

From 8fdc22328b0932f2360f722e36a7f1ac7e5e5a20 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sat, 17 Sep 2016 11:05:07 -0700
Subject: [PATCH] Define _GNU_SOURCE in files delaying config.h

Problem reported by Richard Copley in:
http://lists.gnu.org/archive/html/emacs-devel/2016-09/msg00440.html
* src/w32.c, src/w32notify.c, src/w32proc.c (_GNU_SOURCE):
Define early.
---
 src/unexmacosx.c | 5 +----
 src/w32.c        | 3 +++
 src/w32notify.c  | 3 +++
 src/w32proc.c    | 3 +++
 4 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/src/unexmacosx.c b/src/unexmacosx.c
index 2ba67df..185a9d1 100644
--- a/src/unexmacosx.c
+++ b/src/unexmacosx.c
@@ -85,11 +85,8 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
    be changed accordingly.
 */
 
-/* Make symbols like LLONG_WIDTH visible when the Gnulib <limits.h>
-   is included before <config.h>.  */
-#ifndef _GNU_SOURCE
+/* Enable GNU extensions in gnulib replacement headers.  */
 #define _GNU_SOURCE 1
-#endif
 
 /* config.h #define:s malloc/realloc/free and then includes stdlib.h.
    We want the undefined versions, but if config.h includes stdlib.h
diff --git a/src/w32.c b/src/w32.c
index 1db3426..6cb8e74 100644
--- a/src/w32.c
+++ b/src/w32.c
@@ -21,6 +21,9 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
    Geoff Voelker (voelker@cs.washington.edu)                         7-29-94
 */
 
+/* Enable GNU extensions in gnulib replacement headers.  */
+#define _GNU_SOURCE 1
+
 #include <mingw_time.h>
 #include <stddef.h> /* for offsetof */
 #include <stdlib.h>
diff --git a/src/w32notify.c b/src/w32notify.c
index d4a113a..15e8a86 100644
--- a/src/w32notify.c
+++ b/src/w32notify.c
@@ -81,6 +81,9 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
    thread to exit.  The main thread waits for some time for the worker
    thread to exit, and if it doesn't, terminates it forcibly.  */
 
+/* Enable GNU extensions in gnulib replacement headers.  */
+#define _GNU_SOURCE 1
+
 #include <stddef.h>
 #include <errno.h>
 
diff --git a/src/w32proc.c b/src/w32proc.c
index 90cef32..e23b1b3 100644
--- a/src/w32proc.c
+++ b/src/w32proc.c
@@ -22,6 +22,9 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
      Adapted from alarm.c by Tim Fleehart
 */
 
+/* Enable GNU extensions in gnulib replacement headers.  */
+#define _GNU_SOURCE 1
+
 #include <mingw_time.h>
 #include <stdio.h>
 #include <stdlib.h>
-- 
2.7.4

Re: unexmacosx.c and limits.h problem

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Sat, 17 Sep 2016 13:28:05 +0100
> Cc: Paul Eggert <eggert@cs.ucla.edu>, Bob Halley <halley@play-bow.org>, 
> 	Emacs Development <emacs-devel@gnu.org>
> 
> My preprocessed file doesn't show the #include or #define directives.
> It sounds like yours does. Apparently another difference between our
> toolchains. I obtained the preprocessed file the same way you did.

No, there's no difference.  The inclusion evidence is like this:

  # 1 "../lib/limits.h" 1 3

Do you see such a line in the preprocessed file?  If you do, then does
it include this line further down:

  #define LLONG_WIDTH _GL_INTEGER_WIDTH (LLONG_MIN, LLONG_MAX)

I then searched back for _GNU_SOURCE and saw this:

  #define _GNU_SOURCE 1

and a little ways above it I saw this:

  # 1583 "./config.h"

Do you see these?

Etc. etc. -- just go back and look whether the file inclusion I
described happens on your system.

> I suppose the preprocessed source is no use to you, since you don't
> have the same headers unless you update your MSYS, and if you do that
> you won't need anything from me.

If you cannot figure this out, send the preprocessed source of
w32proc.c, sure.  I will take a look.

Thanks.

Re: unexmacosx.c and limits.h problem

[Richard Copley]

On 17 September 2016 at 13:41, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Sat, 17 Sep 2016 13:28:05 +0100
>> Cc: Paul Eggert <eggert@cs.ucla.edu>, Bob Halley <halley@play-bow.org>,
>>       Emacs Development <emacs-devel@gnu.org>
>>
>> My preprocessed file doesn't show the #include or #define directives.
>> It sounds like yours does. Apparently another difference between our
>> toolchains. I obtained the preprocessed file the same way you did.
>
> No, there's no difference.  The inclusion evidence is like this:
>
>   # 1 "../lib/limits.h" 1 3
>
> Do you see such a line in the preprocessed file?

Yes.

> If you do, then does
> it include this line further down:
>
>   #define LLONG_WIDTH _GL_INTEGER_WIDTH (LLONG_MIN, LLONG_MAX)

No.

> I then searched back for _GNU_SOURCE and saw this:
>
>   #define _GNU_SOURCE 1
>
> and a little ways above it I saw this:
>
>   # 1583 "./config.h"
>
> Do you see these?
>
> Etc. etc. -- just go back and look whether the file inclusion I
> described happens on your system.
>
>> I suppose the preprocessed source is no use to you, since you don't
>> have the same headers unless you update your MSYS, and if you do that
>> you won't need anything from me.
>
> If you cannot figure this out, send the preprocessed source of
> w32proc.c, sure.  I will take a look.
>
> Thanks.

Thanks for that. I might have found the difference that makes the
difference. Please see my other message.

Re: unexmacosx.c and limits.h problem

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Sat, 17 Sep 2016 12:28:02 +0100
> Cc: Paul Eggert <eggert@cs.ucla.edu>, Bob Halley <halley@play-bow.org>, 
> 	Emacs Development <emacs-devel@gnu.org>
> 
> >> The Windows build is broken too (with MSYS2), presumably for a similar
> >> reason.
> >
> > It isn't broken here.  Can you show the error messages?
> 
> Sure, give me a few minutes. Did you reconfigure? You need the
> generated limits.h.

The configure script runs automatically when you say "make" in the
top-level directory.  And yes, limit.h was recreated.

I just re-run autogen.sh and the configure script, to make sure -- no
errors in sight.

What GCC version do you have?

Re: unexmacosx.c and limits.h problem

[Richard Copley]

On 17 September 2016 at 12:34, Eli Zaretskii <eliz@gnu.org> wrote:

>> >> The Windows build is broken too (with MSYS2), presumably for a similar
>> >> reason.
>> >
>> > It isn't broken here.  Can you show the error messages?
>>
>> Sure, give me a few minutes. Did you reconfigure? You need the
>> generated limits.h.
>
> The configure script runs automatically when you say "make" in the
> top-level directory.  And yes, limit.h was recreated.
>
> I just re-run autogen.sh and the configure script, to make sure -- no
> errors in sight.
>
> What GCC version do you have?

I refer the honourable gentleman ...