--- Begin Message ---
|
Subject: |
25.0.50; Windows 7: Odd length text property list |
|
Date: |
Mon, 13 Oct 2014 02:58:50 +0200 |
Emacs -Q won't start on a Windows 7 32 bits laptop. It prints the
mentioned message on the console. Same for a Windows 7 64 bits VM.
However, the same binary has no issues on Windows XP 32 bits nor on
Windows 8 64 bits.
It was compiled on a Windows XP machine with MinGW-w64.
The sources are the same used for this instance of Emacs on GNU Linux
that I'm using for writing this report.
There is bug#18559 on Sep 25 about the same problem but it was confirmed
as fixed that same day. My sources are from Oct 4. Also tried an
emacs.exe binary with current trunk.
In GNU Emacs 25.0.50.2 (x86_64-unknown-linux-gnu, X toolkit)
of 2014-10-04 on qcore
Windowing system distributor `The X.Org Foundation', version 11.0.11501000
System Description: Ubuntu 14.04.1 LTS
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#18699: 25.0.50; Windows 7: Odd length text property list |
|
Date: |
Mon, 13 Oct 2014 15:57:17 +0200 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
Eli Zaretskii <address@hidden> writes:
[snip]
> It is a PITA that the MinGW64 compiler doesn't define some clear-cut
> macro for that without the need to include headers. IME this is a
> terrible maintenance headache in the long run.
Agreed.
> 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.
> 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.
>> Eli, can you take care of the ALIGN_STACK fix?
>
> Done in trunk revision 118105.
Thanks!
--- End Message ---