GNU bug report logs - #36597
27.0.50; rehash hash tables eagerly in pdumper

Previous Next

Full log

View this message in rfc822 format

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: 36597 <at> debbugs.gnu.org
Subject: bug#36597: 27.0.50; rehash hash tables eagerly in pdumper
Date: Wed, 12 Aug 2020 21:41:02 +0100

On Wed 12 Aug 2020, Eli Zaretskii wrote:

>> Cc: larsi <at> gnus.org, pipcet <at> gmail.com, 36597 <at> debbugs.gnu.org
>> From: Paul Eggert <eggert <at> cs.ucla.edu>
>> Date: Wed, 12 Aug 2020 12:11:09 -0700
>> 
>> I looked into the MinGW situation and the problem seems to be that MinGW defined 
>> a macro _INTPTR_T_DEFINED that it no longer defines, and Gnulib was keying off 
>> that no-longer-present macro.
>
> I think _INTPTR_T_DEFINED is still being used, but only by MinGW64.  I
> use mingw.org's MinGW, where that macro was never used.

Yes, MinGW64 still defines this in corecrt.h, and in _cygwin.h (which I
think is to support cross conpiling to cygwin).

> However, both MinGW flavors typedef intptr_t as 'int', not 'long int',
> on 32-bit platforms.

Agreed.

>> I installed a patch for that in Gnulib here:
>> 
>> https://lists.gnu.org/r/bug-gnulib/2020-08/msg00088.html
>> 
>> and migrated the patch into Emacs. Hope it fixes things.
>
> It does here, thanks.  I hope someone will be able to make sure
> MinGW64 builds are not adversely affected (I don't think they should
> be).

On msys2, 32bit mingw64 and 64bit mingw64 builds are both ok (using
commit fd6058b8).

    AndyM

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.