From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: unexmacosx.c and limits.h problem Date: Sat, 17 Sep 2016 14:51:22 +0300 Message-ID: <83a8f64udh.fsf@gnu.org> References: <17A5977B-7474-4740-BEC7-CFF27E57FC73@play-bow.org> <83d1k24vvr.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1474113119 25542 195.159.176.226 (17 Sep 2016 11:51:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 17 Sep 2016 11:51:59 +0000 (UTC) Cc: halley@play-bow.org, eggert@cs.ucla.edu, emacs-devel@gnu.org To: Richard Copley Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 17 13:51:54 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1blE9p-00051j-2T for ged-emacs-devel@m.gmane.org; Sat, 17 Sep 2016 13:51:45 +0200 Original-Received: from localhost ([::1]:45729 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1blE9n-0000yb-Bh for ged-emacs-devel@m.gmane.org; Sat, 17 Sep 2016 07:51:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58066) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1blE9g-0000xl-FX for emacs-devel@gnu.org; Sat, 17 Sep 2016 07:51:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1blE9b-0005dF-A2 for emacs-devel@gnu.org; Sat, 17 Sep 2016 07:51:35 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50591) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1blE9b-0005ci-6e; Sat, 17 Sep 2016 07:51:31 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1622 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1blE9T-0002tO-2X; Sat, 17 Sep 2016 07:51:29 -0400 In-reply-to: (message from Richard Copley on Sat, 17 Sep 2016 12:31:36 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:207481 Archived-At: > From: Richard Copley > Date: Sat, 17 Sep 2016 12:31:36 +0100 > Cc: Paul Eggert , Bob Halley , > Emacs Development > > >>> >> +#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.)