From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Richard Copley Newsgroups: gmane.emacs.devel Subject: Re: unexmacosx.c and limits.h problem Date: Sat, 17 Sep 2016 13:40:52 +0100 Message-ID: References: <17A5977B-7474-4740-BEC7-CFF27E57FC73@play-bow.org> <83d1k24vvr.fsf@gnu.org> <83a8f64udh.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: blaine.gmane.org 1474116127 32677 195.159.176.226 (17 Sep 2016 12:42:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 17 Sep 2016 12:42:07 +0000 (UTC) Cc: Bob Halley , Paul Eggert , Emacs Development To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 17 14:42:02 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 1blEwP-0007Kg-GD for ged-emacs-devel@m.gmane.org; Sat, 17 Sep 2016 14:41:57 +0200 Original-Received: from localhost ([::1]:46084 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1blEwN-0007V0-MU for ged-emacs-devel@m.gmane.org; Sat, 17 Sep 2016 08:41:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39451) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1blEvu-0007JG-JG for emacs-devel@gnu.org; Sat, 17 Sep 2016 08:41:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1blEvt-0001VP-BD for emacs-devel@gnu.org; Sat, 17 Sep 2016 08:41:26 -0400 Original-Received: from mail-vk0-x22c.google.com ([2607:f8b0:400c:c05::22c]:35770) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1blEvr-0001UF-Bd; Sat, 17 Sep 2016 08:41:23 -0400 Original-Received: by mail-vk0-x22c.google.com with SMTP id b133so61696984vka.2; Sat, 17 Sep 2016 05:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Vix/vnKowbGcAQ0E0AIYDCOgfp3TtFcYdZhRFDJDxOM=; b=ril+pncuD51xaZJI6zULzMU3domUi0NrkzHfgp9YYsy6ETpX21nYNTvjwSs+NCmJ9c PRk4Lus2iTXXG3d3FKkJdIcmc4CYYNPSKABwkzaNwGV4ZFmyuDlU0rmjZS0M5ZaRCfMQ +n9JERNMKtJyDRC0K2Q5PAfy2MIfF1tG5UuLJZcUxMxPY4P6O2oiObgJ0ghsQd8i7umy UH/W7lzZy8XIcAIi6wtgKWP+eu5UckqxiPKNuiAvqPg1AjkFFwWKZ0h36j7rNipU/2MB qPcrDWLOsOSvInQzshiwdLssSZAT5NtMfULt2g2uSKLhQaEIPJu9U5rJ+wppaQWnTuot 4Gdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Vix/vnKowbGcAQ0E0AIYDCOgfp3TtFcYdZhRFDJDxOM=; b=nJd1gPHYbHsRXtk1KXd1VC/5YEv+gDpFijlvcUsd3Wf1N/R3I08dzuzaoD7Xk+/T2N EZFpKME/5VBGrl7KbjcTLuXKh1Oru3oseJZvcGhWGBljznhgXJpkgPN5CBSb8tDGYjNu rUX4fNjfdDHpi5N9xPCccGiG7YNiCr3tlLc4mEo4gb1RTTFSfc89deOBWC3XWULNQMFB ejOdqe1roiDbSRvyOrVbQkQXLiF8eozlh5kUXyt50YFoShyLlwoTiNr/rAhtNgomSJRz gCNyu7vZ7Fy7yxQS9MiZg0hiTc21dUdEFPRPHkliu6s/w8y1xoMZxBJH5lsk70w7mmwm seWg== X-Gm-Message-State: AE9vXwNRCR2foI6bQzz8ygujS45sRFNOQJ7UrxJEwcK7vodCDHOoIIQzO/xf9qmT9f7/+GpmZ4+oufKgTGKz4g== X-Received: by 10.31.235.67 with SMTP id j64mr6220885vkh.45.1474116082849; Sat, 17 Sep 2016 05:41:22 -0700 (PDT) Original-Received: by 10.176.82.176 with HTTP; Sat, 17 Sep 2016 05:40:52 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400c:c05::22c 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:207483 Archived-At: On 17 September 2016 at 13:28, Richard Copley wrote: > On 17 September 2016 at 12:51, Eli Zaretskii wrote: >>> 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.) > > 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 ^~~~~