From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.comp.lib.gnulib.bugs,gmane.emacs.devel Subject: Re: Emacs build fails on Windows mingw64 Date: Sun, 24 Oct 2021 09:26:17 +0300 Message-ID: <83ee8b3pme.fsf@gnu.org> References: <86v91nfp6e.fsf@gmail.com> <0b467abe-dd50-6a0a-7d1f-37eb990900be@cs.ucla.edu> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12194"; mail-complaints-to="usenet@ciao.gmane.io" Cc: bug-gnulib@gnu.org, andrewjmoreton@gmail.com, emacs-devel@gnu.org To: Paul Eggert Original-X-From: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane-mx.org@gnu.org Sun Oct 24 08:26:37 2021 Return-path: Envelope-to: gnu-bug-gnulib@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1meWxp-0002w8-Bn for gnu-bug-gnulib@m.gmane-mx.org; Sun, 24 Oct 2021 08:26:37 +0200 Original-Received: from localhost ([::1]:47750 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1meWxn-0007Bo-QZ for gnu-bug-gnulib@m.gmane-mx.org; Sun, 24 Oct 2021 02:26:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55380) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1meWxh-0007AX-6a; Sun, 24 Oct 2021 02:26:29 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52410) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1meWxg-00074o-25; Sun, 24 Oct 2021 02:26:28 -0400 Original-Received: from [87.69.77.57] (port=4164 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1meWxf-0001vW-L2; Sun, 24 Oct 2021 02:26:27 -0400 In-Reply-To: <0b467abe-dd50-6a0a-7d1f-37eb990900be@cs.ucla.edu> (message from Paul Eggert on Sat, 23 Oct 2021 23:45:04 -0400) X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnulib" Xref: news.gmane.io gmane.comp.lib.gnulib.bugs:45174 gmane.emacs.devel:277642 Archived-At: > From: Paul Eggert > Date: Sat, 23 Oct 2021 23:45:04 -0400 > Cc: bug-gnulib@gnu.org, emacs-devel@gnu.org > > On 10/23/21 4:42 PM, Andy Moreton wrote: > > Can this issue be addressed in gnulib so the emacs bug can be fixed ? > > This appears to be an issue in Emacs not Gnulib, as a few of Emacs's > MS-Windows-specific files don't include first, which is a > documented requirement for Gnulib-using apps. Proposed Emacs patch > attached. I haven't tested or installed this, as I don't use MingW. This solution cannot be used, because ntlib cannot include config.h, due to various redefinitions and redirections we do in ms-w32.h for Emacs. (We could redesign these tricks, but that's a lot of tedium, and cannot be done on the release branch anyway.) Let me turn the table and ask why that declaration of strdup is at all needed in Gnulib's string.h when it's used in MinGW builds? strdup is available natively in the MS C runtime, and its prototype is already in the system's string.h header. I'm aware that Gnulib has strdup.c, but we don't currently use it in Emacs, and even if we will at some point, we won't use it in the MinGW build. So how about ifdef-ing that declaration away for MinGW in the Gnulib header?