GNU bug report logs - #18699
25.0.50; Windows 7: Odd length text property list

Previous Next

Full log

Message #44 received at 18699 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, Óscar Fuentes
 <oscarfv <at> telefonica.net>
Cc: 18699 <at> debbugs.gnu.org
Subject: Re: bug#18699: 25.0.50; Windows 7: Odd length text property list
Date: Mon, 13 Oct 2014 15:14:53 -0400

On 10/13/2014 3:07 PM, Eli Zaretskii wrote:
>> From: oscarfv <at> telefonica.net (Óscar Fuentes)
>> Cc: 18699-done <at> debbugs.gnu.org
>> Date: Mon, 13 Oct 2014 15:57:17 +0200
>>
>>> Perhaps you could ask the MinGW64 developers to change their mind
>>> about that.
>>
>> I could try, but my understanding is that they are not interested on
>> doing that, for multiple reasons. One of them is that, in theory, you
>> could use the MinGW-w64 compiler with the MinGW headers and libraries.
>
> That's a nice theory, but I don't think it will hold, since (AFAIU)
> the two compilers use different methods of throwing C++ exceptions
> between DLLs.
>
>>> What about __x86_64__, does it perhaps fit the bill already?
>>
>> __x86_64__ is about the processor. It is also defined by gcc 4.8.2 on my
>> Kubuntu x86_64. Of course, being MinGW on x86_64 implies Windows 64. But
>> I've seen quite a few patch submissions about ARM support on the
>> MinGW-w64 ml, so an hypothetical Emacs compiled for Windows ARM 64bits
>> by MinGW would fail the __x86_64__ test. If that Emacs comes to light,
>> we probably would need to determine what's the right thing wrt
>> ALIGN_STACK, though.
>>
>> So in this specific case __x86_64__ does not harm, but it is superfluous
>> on the presence on _WIN64.
>
> It is there for Cygwin's sake,

Right.  And it's *not* about the processor.  gcc running under 32-bit 
Cygwin will not define __x86_64__, regardless of the processor.

Ken

Previous Next

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