GNU bug report logs - #56853
29.0.50; MacOS installation broken

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 56853 in the body.
You can then email your comments to 56853 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; MacOS installation broken
Date: Sun, 31 Jul 2022 14:35:39 +0200

With ac237334c7672377721e4d27e8ecd6b09d453568 running Emacs from
Emacs.app is broken.  Steps to reproduce:

git clean -xdf
./autogen.sh
./configure --with-native-compilation
make
make install
Move nextstep/Emacs.app to /Applications
start /Applications/Emacs.app with double-click
=> nothing happens

Running Emacs from a shell:

~/emacs/master/ > /Applications/Emacs.app/Contents/MacOS/Emacs 
Loading loadup.el (source)...
Dump mode: nil
Using load-path (/Applications/Emacs.app/Contents/Resources/site-lisp /Applications/Emacs.app/Contents/Resources/lisp /Applications/Emacs.app/Contents/Resources/lisp/emacs-lisp /Applications/Emacs.app/Contents/Resources/lisp/progmodes /Applications/Emacs.app/Contents/Resources/lisp/language /Applications/Emacs.app/Contents/Resources/lisp/international /Applications/Emacs.app/Contents/Resources/lisp/textmodes /Applications/Emacs.app/Contents/Resources/lisp/vc)
Loading emacs-lisp/debug-early...
Symbol's function definition is void: file-name-sans-extension

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: 56853 <at> debbugs.gnu.org
Subject: Re: bug#56853: 29.0.50; MacOS installation broken
Date: Sun, 31 Jul 2022 15:35:42 +0200

Don't know if this is helpful.  Alas, I'm not quite on top of what's
going on in master.

Apparently, the error is signaled from C:

(lldb) xbacktrace 
(unsigned char *) data = 0x00000001030ab538 "file-name-sans-extension"
(unsigned char *) data = 0x0000000100284848 "defalias"
(unsigned char *) data = 0x000000010028a02f "load"
(unsigned char *) data = 0x000000010028a02f "load"


 frame #0: 0x0000000100258b78 Emacs`Fsignal(error_symbol=-> (struct Lisp_Symbol *) $2 = 0x00000001006a1a50, data=-> (EMACS_INT) $4 = 1086473292) at eval.c:1687:27 [opt]
   1684	  (Lisp_Object error_symbol, Lisp_Object data)
   1685	{
   1686	  /* If they call us with nonsensical arguments, produce "peculiar error".  */
-> 1687	  if (NILP (error_symbol) && NILP (data))
   1688	    error_symbol = Qerror;
   1689	  signal_or_quit (error_symbol, data, false);
   1690	  eassume (false);
Target 0: (Emacs) stopped.
(lldb) up
frame #1: 0x0000000100258bb0 Emacs`xsignal(error_symbol=<unavailable>, data=<unavailable>) at lisp.h:4550:3 [opt]
   4547	INLINE AVOID
   4548	xsignal (Lisp_Object error_symbol, Lisp_Object data)
   4549	{
-> 4550	  Fsignal (error_symbol, data);
   4551	}
   4552	extern AVOID xsignal0 (Lisp_Object);
   4553	extern AVOID xsignal1 (Lisp_Object, Lisp_Object);
(lldb) 
frame #2: 0x0000000100258988 Emacs`xsignal1(error_symbol=<unavailable>, arg=<unavailable>) at eval.c:0:26 [opt]
   1844	}
   1845	
   1846	void
-> 1847	xsignal1 (Lisp_Object error_symbol, Lisp_Object arg)
   1848	{
   1849	  xsignal (error_symbol, list1 (arg));
   1850	}
Note: this address is compiler-generated code in function xsignal1 that has no source code associated with it.
(lldb) 

frame #3: 0x000000010016fb80 Emacs`funcall_general(fun=<unavailable>, numargs=<unavailable>, args=<unavailable>) at eval.c:2912:2 [opt]
   2909	  else
   2910	    {
   2911	      if (NILP (fun))
-> 2912		xsignal1 (Qvoid_function, original_fun);
   2913	      if (!CONSP (fun))
   2914		xsignal1 (Qinvalid_function, original_fun);
   2915	      Lisp_Object funcar = XCAR (fun);
(lldb) 
frame #4: 0x000000010016c368 Emacs`Ffuncall(nargs=2, args=-> (struct Lisp_Symbol *) $64 = 0x0000000100691a30) at eval.c:2958:21 [opt]
   2955	  if (debug_on_next_call)
   2956	    do_debug_on_call (Qlambda, count);
   2957	
-> 2958	  Lisp_Object val = funcall_general (args[0], nargs - 1, args + 1);
   2959	
   2960	  lisp_eval_depth--;
   2961	  if (backtrace_debug_on_exit (specpdl_ref_to_ptr (count)))
(lldb) 
frame #5: 0x00000001001c0b88 Emacs`maybe_defer_native_compilation(function_name=-> (struct Lisp_Symbol *) $67 = 0x00000001100082c0, definition=-> (struct Lisp_Vector *) $72 = 0x000000011000d5a8) at comp.c:5120:14 [opt]
   5117	    return;
   5118	
   5119	  Lisp_Object src =
-> 5120	    concat2 (CALL1I (file-name-sans-extension, Vload_true_file_name),
   5121		     build_pure_c_string (".el"));
   5122	  if (NILP (Ffile_exists_p (src)))
   5123	    {

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 56853 <at> debbugs.gnu.org
Subject: Re: bug#56853: 29.0.50; MacOS installation broken
Date: Sun, 31 Jul 2022 20:35:02 +0300

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Date: Sun, 31 Jul 2022 15:35:42 +0200
> 
> 
> Don't know if this is helpful.  Alas, I'm not quite on top of what's
> going on in master.

It builds fine for me, with native-compilation, on GNU/Linux.

Did you succeed in understanding how the offending commit is related
to the error about file-name-sans-extension?

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 56853 <at> debbugs.gnu.org
Subject: Re: bug#56853: 29.0.50; MacOS installation broken
Date: Sun, 31 Jul 2022 19:51:00 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Date: Sun, 31 Jul 2022 15:35:42 +0200
>> 
>> 
>> Don't know if this is helpful.  Alas, I'm not quite on top of what's
>> going on in master.
>
> It builds fine for me, with native-compilation, on GNU/Linux.
>
> Did you succeed in understanding how the offending commit is related
> to the error about file-name-sans-extension?

No, I didn't yet look deeper into this.  I suspect that it has something
to do with one or more of Lars' commits regarding loaddefs.el.  But
that's a wild guess, I don't yet understand what Lars did.

If it works on GNU/Linux that hints at something specific to the macOS
installation procedure, which copies all sorts of files to form an "app
bundle", basically a directory containing everything belonging to an
application.  The easiest explanation would be if the copy misses a file
that isn't copied, or it copies too much.

I'll continue to investigate this tomorrow.

Thanks.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 56853 <at> debbugs.gnu.org
Subject: Re: bug#56853: 29.0.50; MacOS installation broken
Date: Mon, 01 Aug 2022 09:07:23 +0800

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> With ac237334c7672377721e4d27e8ecd6b09d453568 running Emacs from
> Emacs.app is broken.  Steps to reproduce:
>
> git clean -xdf
> ./autogen.sh
> ./configure --with-native-compilation
> make
> make install
> Move nextstep/Emacs.app to /Applications
> start /Applications/Emacs.app with double-click
> => nothing happens
>
> Running Emacs from a shell:
>
> ~/emacs/master/ > /Applications/Emacs.app/Contents/MacOS/Emacs 
> Loading loadup.el (source)...
> Dump mode: nil
> Using load-path (/Applications/Emacs.app/Contents/Resources/site-lisp
> /Applications/Emacs.app/Contents/Resources/lisp
> /Applications/Emacs.app/Contents/Resources/lisp/emacs-lisp
> /Applications/Emacs.app/Contents/Resources/lisp/progmodes
> /Applications/Emacs.app/Contents/Resources/lisp/language
> /Applications/Emacs.app/Contents/Resources/lisp/international
> /Applications/Emacs.app/Contents/Resources/lisp/textmodes
> /Applications/Emacs.app/Contents/Resources/lisp/vc)
> Loading emacs-lisp/debug-early...
> Symbol's function definition is void: file-name-sans-extension

This is probably my fault.  Please see if the following patch helps:

diff --git a/nextstep/Makefile.in b/nextstep/Makefile.in
index ee883f3cff..77aecb1e70 100644
--- a/nextstep/Makefile.in
+++ b/nextstep/Makefile.in
@@ -31,6 +31,7 @@ EXEEXT =
 top_srcdir_abs = $(shell cd @top_srcdir@; pwd -P)
 
 MKDIR_P = @MKDIR_P@
+DUMPING = @DUMPING@
 
 ## Emacs.app.
 ns_appdir = @ns_appdir@

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 56853 <at> debbugs.gnu.org
Subject: Re: bug#56853: 29.0.50; MacOS installation broken
Date: Mon, 01 Aug 2022 07:53:16 +0200

Po Lu <luangruo <at> yahoo.com> writes:

> This is probably my fault.  Please see if the following patch helps:

No, I'm afraid that didn't help.

I did the same steps as before, and get an identical result.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 56853 <at> debbugs.gnu.org
Subject: Re: bug#56853: 29.0.50; MacOS installation broken
Date: Mon, 01 Aug 2022 08:43:58 +0200

I'm bisecting.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 56853 <at> debbugs.gnu.org
Subject: Re: bug#56853: 29.0.50; MacOS installation broken
Date: Mon, 01 Aug 2022 09:57:05 +0200

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> I'm bisecting.

I've pushed a fix to master.  It was the change you thought of, Lu, but
there was an additional typo further down in Makefile.in.

BTW, how do I say your name correctly?  What's your first name?  Or do I
say both?

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

From: Po Lu <luangruo <at> yahoo.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 56853 <at> debbugs.gnu.org
Subject: Re: bug#56853: 29.0.50; MacOS installation broken
Date: Mon, 01 Aug 2022 16:15:18 +0800

> I've pushed a fix to master.  It was the change you thought of, Lu, but
> there was an additional typo further down in Makefile.in.

Thanks.  Sorry for the trouble.

> BTW, how do I say your name correctly?  What's your first name?  Or do I
> say both?

Both would be preferable, thanks.

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

From: Andrea Corallo <akrl <at> sdf.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 56853 <at> debbugs.gnu.org
Subject: Re: bug#56853: 29.0.50; MacOS installation broken
Date: Mon, 01 Aug 2022 09:51:24 +0000

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> Don't know if this is helpful.  Alas, I'm not quite on top of what's
> going on in master.
>
> Apparently, the error is signaled from C:
>
> (lldb) xbacktrace 
> (unsigned char *) data = 0x00000001030ab538 "file-name-sans-extension"
> (unsigned char *) data = 0x0000000100284848 "defalias"
> (unsigned char *) data = 0x000000010028a02f "load"
> (unsigned char *) data = 0x000000010028a02f "load"
>
>
>  frame #0: 0x0000000100258b78 Emacs`Fsignal(error_symbol=-> (struct Lisp_Symbol *) $2 = 0x00000001006a1a50, data=-> (EMACS_INT) $4 = 1086473292) at eval.c:1687:27 [opt]
>    1684	  (Lisp_Object error_symbol, Lisp_Object data)
>    1685	{
>    1686	  /* If they call us with nonsensical arguments, produce "peculiar error".  */
> -> 1687	  if (NILP (error_symbol) && NILP (data))
>    1688	    error_symbol = Qerror;
>    1689	  signal_or_quit (error_symbol, data, false);
>    1690	  eassume (false);
> Target 0: (Emacs) stopped.
> (lldb) up
> frame #1: 0x0000000100258bb0 Emacs`xsignal(error_symbol=<unavailable>, data=<unavailable>) at lisp.h:4550:3 [opt]
>    4547	INLINE AVOID
>    4548	xsignal (Lisp_Object error_symbol, Lisp_Object data)
>    4549	{
> -> 4550	  Fsignal (error_symbol, data);
>    4551	}
>    4552	extern AVOID xsignal0 (Lisp_Object);
>    4553	extern AVOID xsignal1 (Lisp_Object, Lisp_Object);
> (lldb) 
> frame #2: 0x0000000100258988 Emacs`xsignal1(error_symbol=<unavailable>, arg=<unavailable>) at eval.c:0:26 [opt]
>    1844	}
>    1845	
>    1846	void
> -> 1847	xsignal1 (Lisp_Object error_symbol, Lisp_Object arg)
>    1848	{
>    1849	  xsignal (error_symbol, list1 (arg));
>    1850	}
> Note: this address is compiler-generated code in function xsignal1 that has no source code associated with it.
> (lldb) 
>
> frame #3: 0x000000010016fb80 Emacs`funcall_general(fun=<unavailable>, numargs=<unavailable>, args=<unavailable>) at eval.c:2912:2 [opt]
>    2909	  else
>    2910	    {
>    2911	      if (NILP (fun))
> -> 2912		xsignal1 (Qvoid_function, original_fun);
>    2913	      if (!CONSP (fun))
>    2914		xsignal1 (Qinvalid_function, original_fun);
>    2915	      Lisp_Object funcar = XCAR (fun);
> (lldb) 
> frame #4: 0x000000010016c368 Emacs`Ffuncall(nargs=2, args=-> (struct Lisp_Symbol *) $64 = 0x0000000100691a30) at eval.c:2958:21 [opt]
>    2955	  if (debug_on_next_call)
>    2956	    do_debug_on_call (Qlambda, count);
>    2957	
> -> 2958	  Lisp_Object val = funcall_general (args[0], nargs - 1, args + 1);
>    2959	
>    2960	  lisp_eval_depth--;
>    2961	  if (backtrace_debug_on_exit (specpdl_ref_to_ptr (count)))
> (lldb) 
> frame #5: 0x00000001001c0b88 Emacs`maybe_defer_native_compilation(function_name=-> (struct Lisp_Symbol *) $67 = 0x00000001100082c0, definition=-> (struct Lisp_Vector *) $72 = 0x000000011000d5a8) at comp.c:5120:14 [opt]
>    5117	    return;
>    5118	
>    5119	  Lisp_Object src =
> -> 5120	    concat2 (CALL1I (file-name-sans-extension, Vload_true_file_name),
>    5121		     build_pure_c_string (".el"));
>    5122	  if (NILP (Ffile_exists_p (src)))
>    5123	    {

I think what is going on is that while starting we get into
'maybe_defer_native_compilation' where we try to call
`file-name-sans-extension' but this is stil not defined for some reason.
Now why this condition happen has still to be determined.

Perhaps someone should compare this startup sequence with the working
non moved binary?

Thanks

  Andrea

Previous Next

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