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

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

bug#45455: [nextstep]: Emacs master does not compile on Apple Silicon (a


From: Artem Loenko
Subject: bug#45455: [nextstep]: Emacs master does not compile on Apple Silicon (arm64)
Date: Sun, 27 Dec 2020 20:12:52 +0000

Looks strange indeed. 

I see that these changes were introduced in this commit – 
https://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-27&id=fda9b3e83a434706c31ab1bee5c15511c0181d5a
 So, emacs-27 branch does not compile on Apple Silicon as well any more. Also, 
I believe, it should be at least `arm64-apple-darwin` and not 
`arm-apple-darwin`. Though, I tried to compile with `arm64-apple-darwin` but 
got the same error with `temacs`.

I checked LLVM bundled with Xcode 12.3 and LLVM 11.0.0. Both report 
`arm64-apple-darwin` as a target (the same for `-print-effective-triple`:

> ~/Projects/emacs $ /opt/homebrew/opt/llvm/bin/clang --version
> clang version 11.0.0
> Target: arm64-apple-darwin20.2.0
> Thread model: posix
> InstalledDir: /opt/homebrew/opt/llvm/bin

> ~/Projects/emacs $ xcrun clang --version
> Apple clang version 12.0.0 (clang-1200.0.32.28)
> Target: arm64-apple-darwin20.2.0
> Thread model: posix
> InstalledDir: 
> /Volumes/Extended/Archives/Xcode_12.3.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Though, during the ./configure, `config.guess` identifies the system as 
`aarch64-apple-darwin`:

> Running ./configure ...
> ./configure
> ...
> checking build system type... aarch64-apple-darwin20.2.0
> checking host system type... aarch64-apple-darwin20.2.0
>
> Configured for 'aarch64-apple-darwin20.2.0’.

> ~/Projects/emacs $ ./build-aux/config.guess
> aarch64-apple-darwin20.2.0

It seems that `clang` is good with both versions as a target.

Anyway, the fact is that `temacs` works fine with `aarch64-apple-darwin` target 
and does not with `arm(64)-apple-darwin`. I do not know much about `temacs` and 
Emacs internals, if you have any leads or theories to check – let me know, I 
will try my best. So far, my best idea is that we propagate the target to other 
tool that does not “understand” `arm64-apple-darwin`.

Regards,
Artem Loenko

> On 27 Dec 2020, at 14:12, Philipp Stephani <p.stephani2@gmail.com> wrote:
> 
> Am So., 27. Dez. 2020 um 12:54 Uhr schrieb Artem Loenko via Bug
> reports for GNU Emacs, the Swiss army knife of text editors
> <bug-gnu-emacs@gnu.org>:
>> 
>> Hello there,
>> 
>> Emacs master (as of 8bc727d0b4 "Fix the recent `length' doc string addition" 
>> commit) does not compile on Apple Silicon (M1) anymore. Compilation fails 
>> with the following error:
>> 
>> ./temacs --batch  -l loadup --temacs=pbootstrap
>> make[1]: *** [bootstrap-emacs.pdmp] Killed: 9
>> make: *** [src] Error 2
>> 
>> When you try to run the `temacs` under lldb, it shows the following problem:
>> 
>> (lldb) process launch
>> Process 75320 launched: '/Users/dive/Projects/emacs/src/temacs' (arm64)
>> Loading loadup.el (source)...
>> ...
>> Eager macro-expansion failure: (void-variable search-slow-speed)
>> Eager macro-expansion failure: (void-variable search-slow-speed)
>> Symbol’s value as variable is void: search-slow-speed
>> Process 75320 exited with status = 255 (0x000000ff)
>> 
>> The problem was introduced in the "Merge from origin/emacs-27” commit – 
>> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=90ec81f5b243b6b7b3ebe2de394b20e8078ebc96
>>  and I believe it was unintentional revert of DO_CODESIGN within 
>> src/Makefile.in:
>> 
>> diff --git a/src/Makefile.in b/src/Makefile.in
>> index 39c0f12fe6..19304cca04 100644
>> --- a/src/Makefile.in
>> +++ b/src/Makefile.in
>> @@ -338,7 +338,7 @@ HAVE_PDUMPER = @HAVE_PDUMPER@
>> 
>> ## ARM Macs require that all code have a valid signature.  Since pump
>> ## invalidates the signature, we must re-sign to fix it.
>> -DO_CODESIGN=$(patsubst aarch64-apple-darwin%,yes,@configuration@)
>> +DO_CODESIGN=$(patsubst arm-apple-darwin%,yes,@configuration@)
> 
> For some reason the @configuration@ value on my system is occasionally
> either arm-... or aarch64-..., without a clear pattern. Should we
> maybe accept both? Or can we make sure that aarch64-... is detected
> consistently?






reply via email to

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