bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#36597: 27.0.50; rehash hash tables eagerly in pdumper


From: Andy Moreton
Subject: bug#36597: 27.0.50; rehash hash tables eagerly in pdumper
Date: Wed, 12 Aug 2020 21:41:02 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (windows-nt)

On Wed 12 Aug 2020, Eli Zaretskii wrote:

>> Cc: larsi@gnus.org, pipcet@gmail.com, 36597@debbugs.gnu.org
>> From: Paul Eggert <eggert@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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]