Re: unexmacosx.c and limits.h problem

[Richard Copley <rcopley@gmail.com>]

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.