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: Philipp Stephani
Subject: bug#45455: [nextstep]: Emacs master does not compile on Apple Silicon (arm64)
Date: Sun, 27 Dec 2020 15:12:36 +0100

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]