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:28:05 +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 1474115341 17105 195.159.176.226 (17 Sep 2016 12:29:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 17 Sep 2016 12:29:01 +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:28:57 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 1blEjh-00036C-Cn for ged-emacs-devel@m.gmane.org; Sat, 17 Sep 2016 14:28:49 +0200 Original-Received: from localhost ([::1]:46050 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1blEjf-0005nH-2N for ged-emacs-devel@m.gmane.org; Sat, 17 Sep 2016 08:28:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37202) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1blEjY-0005nA-MR for emacs-devel@gnu.org; Sat, 17 Sep 2016 08:28:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1blEjW-000239-II for emacs-devel@gnu.org; Sat, 17 Sep 2016 08:28:39 -0400 Original-Received: from mail-vk0-x22e.google.com ([2607:f8b0:400c:c05::22e]:32995) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1blEjT-00021h-Rd; Sat, 17 Sep 2016 08:28:35 -0400 Original-Received: by mail-vk0-x22e.google.com with SMTP id 192so63305885vkl.0; Sat, 17 Sep 2016 05:28:35 -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=sfJc6RAooi2VxNsBSHGYeneRgdQULMWL3LRpUGFLNYk=; b=vexGFzoawzuFc6AgLeBCz6x+oM8b4opTJ/0ADqa13YqacLx7sDBcp4bkNs3zIQ0VWb +iUS3SJymg15GoR2Gihe1dzNTgSRoh1mYEcmVowbdzNd46Zmvm+YtY5rsJC7I71xBROM ga8XxxoWuPFXMrUOU506FoUPEUlXIxOtEP/Pg1WpBS32ETFSG7xvHEBF6XNeoNF5iqok x0ELH0gXqahPuwSrXx1GuQzMiEG6qmcYZOKXIZin3jbmhx7riP/OsOfl4WYqfAGpRlKN G4V6kcWvguiUpJ72xxCBXZckn4kh9eVsybYyHNOi2qp+KDAJOg1JR582+oy02kSfaXdE LaEw== 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=sfJc6RAooi2VxNsBSHGYeneRgdQULMWL3LRpUGFLNYk=; b=EcKZAO4+AQSVj+B5WQMs1/Pd9XLRPDajQT3EjPESAUSpFb5Qi+crrTAeUnwwlW/dW/ VGQCl9TnyhSHku5WfOQ9ElAkqlwJoS8vWWCbDV6kIKjvQ5WqDPpSbvy6vBvzIATijLPL LIwZEL+Is4VxKcEGeZagArFO7Og/hQxuSHZVWfB4+9EAhqj/15k74N50RG4CUXuBWf2W ySi61p23TCRVdlCXkzBC7J3zMLUB+LDyuC//EixEQQct8E730aPR+IbHe5GaPlY6w+lx +YcrW4jrgy8ZBKmE6vq5LoS4tXMs64xujr2FuN9cySNZ0u3tZDLMiPkHsjZaTqiI8D1T 4EBA== X-Gm-Message-State: AE9vXwPBj5bEESJ5WcKh2X0IVeKdJXKAnkLU+WNxquEotixRgkkTf43dfqiclvXH8kPPBUUGRLvVYUj0Mq9SWw== X-Received: by 10.31.4.147 with SMTP id 141mr8283039vke.105.1474115315337; Sat, 17 Sep 2016 05:28:35 -0700 (PDT) Original-Received: by 10.176.82.176 with HTTP; Sat, 17 Sep 2016 05:28:04 -0700 (PDT) In-Reply-To: <83a8f64udh.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400c:c05::22e 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:207482 Archived-At: 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.