unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: bug-gnulib@gnu.org, andrewjmoreton@gmail.com, emacs-devel@gnu.org
Subject: Re: Emacs build fails on Windows mingw64
Date: Sun, 24 Oct 2021 09:26:17 +0300	[thread overview]
Message-ID: <83ee8b3pme.fsf@gnu.org> (raw)
In-Reply-To: <0b467abe-dd50-6a0a-7d1f-37eb990900be@cs.ucla.edu> (message from Paul Eggert on Sat, 23 Oct 2021 23:45:04 -0400)

> From: Paul Eggert <eggert@cs.ucla.edu>
> 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 <config.h> 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?



  reply	other threads:[~2021-10-24  6:26 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <86v91nfp6e.fsf@gmail.com>
2021-10-24  3:45 ` Emacs build fails on Windows mingw64 Paul Eggert
2021-10-24  6:26   ` Eli Zaretskii [this message]
2021-10-24 10:50     ` Andy Moreton
2021-10-24 12:27       ` Paul Eggert
2021-10-24 12:25     ` Paul Eggert
2021-10-24 13:58       ` Eli Zaretskii
2021-10-24 17:05         ` Paul Eggert
2021-10-24 17:48           ` Eli Zaretskii
2021-10-24 17:57           ` Andy Moreton
2021-10-24 22:52             ` Bruno Haible
2021-10-25 11:52               ` Eli Zaretskii
2021-10-25 21:26               ` Andy Moreton
2021-10-24 18:01           ` Óscar Fuentes
2021-10-24 18:10             ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83ee8b3pme.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=andrewjmoreton@gmail.com \
    --cc=bug-gnulib@gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).