Re: unexmacosx.c and limits.h problem

[Richard Copley <rcopley@gmail.com>]

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
  ^~~~~