all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#56853: 29.0.50; MacOS installation broken
@ 2022-07-31 12:35 Gerd Möllmann
  2022-07-31 13:35 ` Gerd Möllmann
  2022-08-01  1:07 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 2 replies; 10+ messages in thread
From: Gerd Möllmann @ 2022-07-31 12:35 UTC (permalink / raw)
  To: 56853


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








^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#56853: 29.0.50; MacOS installation broken
  2022-07-31 12:35 bug#56853: 29.0.50; MacOS installation broken Gerd Möllmann
@ 2022-07-31 13:35 ` Gerd Möllmann
  2022-07-31 17:35   ` Eli Zaretskii
  2022-08-01  9:51   ` Andrea Corallo
  2022-08-01  1:07 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 2 replies; 10+ messages in thread
From: Gerd Möllmann @ 2022-07-31 13:35 UTC (permalink / raw)
  To: 56853


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	    {





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#56853: 29.0.50; MacOS installation broken
  2022-07-31 13:35 ` Gerd Möllmann
@ 2022-07-31 17:35   ` Eli Zaretskii
  2022-07-31 17:51     ` Gerd Möllmann
  2022-08-01  9:51   ` Andrea Corallo
  1 sibling, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2022-07-31 17:35 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: 56853

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#56853: 29.0.50; MacOS installation broken
  2022-07-31 17:35   ` Eli Zaretskii
@ 2022-07-31 17:51     ` Gerd Möllmann
  0 siblings, 0 replies; 10+ messages in thread
From: Gerd Möllmann @ 2022-07-31 17:51 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 56853

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.





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#56853: 29.0.50; MacOS installation broken
  2022-07-31 12:35 bug#56853: 29.0.50; MacOS installation broken Gerd Möllmann
  2022-07-31 13:35 ` Gerd Möllmann
@ 2022-08-01  1:07 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-08-01  5:53   ` Gerd Möllmann
  1 sibling, 1 reply; 10+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-08-01  1:07 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: 56853

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@






^ permalink raw reply related	[flat|nested] 10+ messages in thread

* bug#56853: 29.0.50; MacOS installation broken
  2022-08-01  1:07 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-08-01  5:53   ` Gerd Möllmann
  2022-08-01  6:43     ` Gerd Möllmann
  0 siblings, 1 reply; 10+ messages in thread
From: Gerd Möllmann @ 2022-08-01  5:53 UTC (permalink / raw)
  To: Po Lu; +Cc: 56853

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.





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#56853: 29.0.50; MacOS installation broken
  2022-08-01  5:53   ` Gerd Möllmann
@ 2022-08-01  6:43     ` Gerd Möllmann
  2022-08-01  7:57       ` Gerd Möllmann
  0 siblings, 1 reply; 10+ messages in thread
From: Gerd Möllmann @ 2022-08-01  6:43 UTC (permalink / raw)
  To: Po Lu; +Cc: 56853

I'm bisecting.





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#56853: 29.0.50; MacOS installation broken
  2022-08-01  6:43     ` Gerd Möllmann
@ 2022-08-01  7:57       ` Gerd Möllmann
  2022-08-01  8:15         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 10+ messages in thread
From: Gerd Möllmann @ 2022-08-01  7:57 UTC (permalink / raw)
  To: Po Lu; +Cc: 56853

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?





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#56853: 29.0.50; MacOS installation broken
  2022-08-01  7:57       ` Gerd Möllmann
@ 2022-08-01  8:15         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 0 replies; 10+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-08-01  8:15 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: 56853

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#56853: 29.0.50; MacOS installation broken
  2022-07-31 13:35 ` Gerd Möllmann
  2022-07-31 17:35   ` Eli Zaretskii
@ 2022-08-01  9:51   ` Andrea Corallo
  1 sibling, 0 replies; 10+ messages in thread
From: Andrea Corallo @ 2022-08-01  9:51 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: 56853

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2022-08-01  9:51 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-07-31 12:35 bug#56853: 29.0.50; MacOS installation broken Gerd Möllmann
2022-07-31 13:35 ` Gerd Möllmann
2022-07-31 17:35   ` Eli Zaretskii
2022-07-31 17:51     ` Gerd Möllmann
2022-08-01  9:51   ` Andrea Corallo
2022-08-01  1:07 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-01  5:53   ` Gerd Möllmann
2022-08-01  6:43     ` Gerd Möllmann
2022-08-01  7:57       ` Gerd Möllmann
2022-08-01  8:15         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.