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

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

bug#18699: 25.0.50; Windows 7: Odd length text property list


From: Ken Brown
Subject: bug#18699: 25.0.50; Windows 7: Odd length text property list
Date: Mon, 13 Oct 2014 15:14:53 -0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2

On 10/13/2014 3:07 PM, Eli Zaretskii wrote:
From: oscarfv@telefonica.net (Óscar Fuentes)
Cc: 18699-done@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






reply via email to

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