bug#56853: 29.0.50; MacOS installation broken

bug#56853: 29.0.50; MacOS installation broken

[Gerd Möllmann]

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

bug#56853: 29.0.50; MacOS installation broken

[Gerd Möllmann]

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	    {

bug#56853: 29.0.50; MacOS installation broken

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@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?

bug#56853: 29.0.50; MacOS installation broken

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@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.

bug#56853: 29.0.50; MacOS installation broken

[Andrea Corallo]

Gerd Möllmann <gerd.moellmann@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

bug#56853: 29.0.50; MacOS installation broken

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Gerd Möllmann <gerd.moellmann@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@

bug#56853: 29.0.50; MacOS installation broken

[Gerd Möllmann]

Po Lu <luangruo@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.

bug#56853: 29.0.50; MacOS installation broken

[Gerd Möllmann]

I'm bisecting.

bug#56853: 29.0.50; MacOS installation broken

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@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?

bug#56853: 29.0.50; MacOS installation broken

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> 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.