* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
@ 2022-08-20 12:55 Gerd Möllmann
2022-08-20 13:07 ` Lars Ingebrigtsen
0 siblings, 1 reply; 41+ messages in thread
From: Gerd Möllmann @ 2022-08-20 12:55 UTC (permalink / raw)
To: 57309
I did a git pull and build from scratch this morning at about 8:44,
everyting ok. Pulled again from git master now, new HEAD is
07c04da01016cd81e064a06b2449892eff7c8da0 and did a meke -j8.
This prints a, new to me, error. I'm adding the contents of the
*compilation* buffer below.
In lldb I can see that temacs tries to dump a window.eln built this
morning.
frame #2: 0x0000000100152914 temacs`dump_native_comp_unit(ctx=0x000000016fdfe300, comp_u=0x00000001040d0a68) at pdumper.c:2914:5 [opt]
2911 struct Lisp_Native_Comp_Unit *comp_u)
2912 {
2913 if (!CONSP (comp_u->file))
-> 2914 error ("Trying to dump non fixed-up eln file\n");
2915
2916 /* Have function documentation always lazy loaded to optimize load-time. */
2917 comp_u->data_fdoc_v = Qnil;
(lldb) p comp_u->file
(Lisp_Object) $57 = 0x00000001038186e4 (struct Lisp_String *) $59 = 0x00000001038186e0
(lldb) p *$59
(struct Lisp_String) $60 = {
u = {
s = {
size = 92
size_byte = -1
intervals = NULL
data = 0x0000000103051eb8 "/Users/gerd/emacs/master/native-lisp/29_0_50-2dce7c3a/preloaded/window-0d1b8b93-274db3e2.eln"
}
next = 0x000000000000005c
gcaligned = '\'
}
}
The window.eln looks like this in the file system
~/emacs/master/src/ > ls -l /Users/gerd/emacs/master/native-lisp/29_0_50-2dce7c3a/preloaded/window-0d1b8b93-274db3e2.eln
-rwxr-xr-x 1 gerd staff 612825 Aug 20 08:44 /Users/gerd/emacs/master/native-lisp/29_0_50-2dce7c3a/preloaded/window-0d1b8b93-274db3e2.eln
Other than that, I'm afraid I can't say much more at the moment because
I don't know what the error is telling me.
-*- mode: compilation; default-directory: "~/emacs/master/" -*-
Compilation started at Sat Aug 20 14:14:20
make
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C lib all
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C doc/lispref info
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C doc/lispintro info
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C doc/emacs info
GEN info/dir
make[1]: Nothing to be done for `info'.
make[1]: Nothing to be done for `info'.
make[1]: Nothing to be done for `info'.
make[1]: Nothing to be done for `all'.
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C lib-src all
make[1]: Nothing to be done for `all'.
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C src BIN_DESTDIR=''/Users/gerd/emacs/master/nextstep/Emacs.app/Contents/MacOS/'' \
ELN_DESTDIR='/Users/gerd/emacs/master/nextstep/Emacs.app/Contents/Frameworks/' all
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../admin/charsets all
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../admin/unidata charscript.el
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../admin/unidata emoji-zwj.el
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../admin/charsets cp51932.el
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../admin/charsets eucjp-ms.el
make[2]: Nothing to be done for `eucjp-ms.el'.
make[2]: Nothing to be done for `cp51932.el'.
make[2]: Nothing to be done for `charscript.el'.
make[2]: Nothing to be done for `emoji-zwj.el'.
make[2]: Nothing to be done for `all'.
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../admin/unidata all EMACS="../../src/bootstrap-emacs"
make[2]: Nothing to be done for `all'.
ELC+ELN ../lisp/term/pgtk-win.elc
ELC+ELN ../lisp/term/x-win.elc
rm -f emacs && cp -f temacs emacs
LC_ALL=C ./temacs -batch -l loadup --temacs=pdump \
--bin-dest /Users/gerd/emacs/master/nextstep/Emacs.app/Contents/MacOS/ --eln-dest /Users/gerd/emacs/master/nextstep/Emacs.app/Contents/Frameworks/
Loading loadup.el (source)...
Dump mode: pdump
Using load-path (/Users/gerd/emacs/master/lisp)
Loading emacs-lisp/debug-early (native compiled elisp)...
Loading emacs-lisp/byte-run (native compiled elisp)...
Loading emacs-lisp/backquote (native compiled elisp)...
Loading subr (native compiled elisp)...
Loading keymap (native compiled elisp)...
Loading version (native compiled elisp)...
Loading widget (native compiled elisp)...
Loading custom (native compiled elisp)...
Loading emacs-lisp/map-ynp (native compiled elisp)...
Loading international/mule (native compiled elisp)...
Loading international/mule-conf (native compiled elisp)...
Loading env (native compiled elisp)...
Loading format (native compiled elisp)...
Loading bindings (native compiled elisp)...
Loading window (native compiled elisp)...
Loading files (native compiled elisp)...
Loading emacs-lisp/macroexp (native compiled elisp)...
Loading cus-face (native compiled elisp)...
Loading faces (native compiled elisp)...
Loading loaddefs (native compiled elisp)...
Loading button (native compiled elisp)...
Loading emacs-lisp/cl-preloaded (native compiled elisp)...
Loading emacs-lisp/oclosure (native compiled elisp)...
Loading obarray (native compiled elisp)...
Loading abbrev (native compiled elisp)...
Loading help (native compiled elisp)...
Loading jka-cmpr-hook (native compiled elisp)...
Loading epa-hook (native compiled elisp)...
Loading international/mule-cmds (native compiled elisp)...
Loading case-table (native compiled elisp)...
Loading international/charprop.el (source)...
Loading international/characters (native compiled elisp)...
Loading international/charscript (native compiled elisp)...
Loading international/emoji-zwj (native compiled elisp)...
Loading composite (native compiled elisp)...
Loading language/chinese (native compiled elisp)...
Loading language/cyrillic (native compiled elisp)...
Loading language/indian (native compiled elisp)...
Loading language/sinhala (native compiled elisp)...
Loading language/english (native compiled elisp)...
Loading language/ethiopic (native compiled elisp)...
Loading language/european (native compiled elisp)...
Loading language/czech (native compiled elisp)...
Loading language/slovak (native compiled elisp)...
Loading language/romanian (native compiled elisp)...
Loading language/greek (native compiled elisp)...
Loading language/hebrew (native compiled elisp)...
Loading international/cp51932 (native compiled elisp)...
Loading international/eucjp-ms (native compiled elisp)...
Loading language/japanese (native compiled elisp)...
Loading language/korean (native compiled elisp)...
Loading language/lao (native compiled elisp)...
Loading language/tai-viet (native compiled elisp)...
Loading language/thai (native compiled elisp)...
Loading language/tibetan (native compiled elisp)...
Loading language/vietnamese (native compiled elisp)...
Loading language/misc-lang (native compiled elisp)...
Loading language/utf-8-lang (native compiled elisp)...
Loading language/georgian (native compiled elisp)...
Loading language/khmer (native compiled elisp)...
Loading language/burmese (native compiled elisp)...
Loading language/cham (native compiled elisp)...
Loading language/philippine (native compiled elisp)...
Loading language/indonesian (native compiled elisp)...
Loading indent (native compiled elisp)...
Loading emacs-lisp/cl-generic (native compiled elisp)...
Loading simple (native compiled elisp)...
Loading emacs-lisp/seq (native compiled elisp)...
Loading emacs-lisp/nadvice (native compiled elisp)...
Loading minibuffer (native compiled elisp)...
Loading frame (native compiled elisp)...
Loading startup (native compiled elisp)...
Loading term/tty-colors (native compiled elisp)...
Loading font-core (native compiled elisp)...
Loading emacs-lisp/syntax (native compiled elisp)...
Loading font-lock (native compiled elisp)...
Loading jit-lock (native compiled elisp)...
Loading mouse (native compiled elisp)...
Loading scroll-bar (native compiled elisp)...
Loading select (native compiled elisp)...
Loading emacs-lisp/timer (native compiled elisp)...
Loading emacs-lisp/easymenu (native compiled elisp)...
Loading isearch (native compiled elisp)...
Loading rfn-eshadow (native compiled elisp)...
Loading menu-bar (native compiled elisp)...
Loading tab-bar (native compiled elisp)...
Loading emacs-lisp/lisp (native compiled elisp)...
Loading textmodes/page (native compiled elisp)...
Loading register (native compiled elisp)...
Loading textmodes/paragraphs (native compiled elisp)...
Loading progmodes/prog-mode (native compiled elisp)...
Loading emacs-lisp/lisp-mode (native compiled elisp)...
Loading textmodes/text-mode (native compiled elisp)...
Loading textmodes/fill (native compiled elisp)...
Loading newcomment (native compiled elisp)...
Loading replace (native compiled elisp)...
Loading emacs-lisp/tabulated-list (native compiled elisp)...
Loading buff-menu (native compiled elisp)...
Loading fringe (native compiled elisp)...
Loading emacs-lisp/regexp-opt (native compiled elisp)...
Loading image (native compiled elisp)...
Loading international/fontset (native compiled elisp)...
Loading dnd (native compiled elisp)...
Loading tool-bar (native compiled elisp)...
Loading term/common-win (native compiled elisp)...
Loading international/mule-util (native compiled elisp)...
Loading international/ucs-normalize (native compiled elisp)...
Loading term/ns-win (native compiled elisp)...
Loading mwheel (native compiled elisp)...
Loading progmodes/elisp-mode (native compiled elisp)...
Loading emacs-lisp/float-sup (native compiled elisp)...
Loading vc/vc-hooks (native compiled elisp)...
Loading vc/ediff-hook (native compiled elisp)...
Loading uniquify (native compiled elisp)...
Loading electric (native compiled elisp)...
Loading paren (native compiled elisp)...
Loading emacs-lisp/shorthands (native compiled elisp)...
Loading emacs-lisp/eldoc (native compiled elisp)...
Loading cus-start (native compiled elisp)...
Loading tooltip (native compiled elisp)...
Loading international/iso-transl (native compiled elisp)...
Loading leim/leim-list.el (source)...
Loading emacs-lisp/rmc (native compiled elisp)...
Waiting for git...
Waiting for git...
Finding pointers to doc strings...
Finding pointers to doc strings...done
Pure-hashed: 17529 strings, 1734 vectors, 43573 conses, 1071 bytecodes, 348 others
Dumping under the name emacs.pdmp
Dumping fingerprint: c25325106c23d6c52dba3bb9f72bade38e80e766a4daa62deaf35ba3fa5d2295
Dump complete
Byte counts: header=100 hot=14241444 discardable=190248 cold=9791728
Reloc counts: hot=843771 discardable=5208
Adding name emacs-29.0.50.2
Adding name emacs-29.0.50.2.pdmp
cp -f emacs.pdmp bootstrap-emacs.pdmp
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../nextstep all
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../src emacs
/opt/homebrew/bin/gmkdir -p /Users/gerd/emacs/master/nextstep/Emacs.app/Contents/MacOS/libexec
cp -f ../src/emacs.pdmp /Users/gerd/emacs/master/nextstep/Emacs.app/Contents/MacOS/libexec/Emacs.pdmp
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../admin/charsets all
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../admin/unidata charscript.el
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../admin/unidata emoji-zwj.el
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../admin/charsets cp51932.el
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../admin/charsets eucjp-ms.el
make[4]: Nothing to be done for `cp51932.el'.
make[4]: Nothing to be done for `eucjp-ms.el'.
make[4]: Nothing to be done for `emoji-zwj.el'.
make[4]: Nothing to be done for `charscript.el'.
make[4]: Nothing to be done for `all'.
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../admin/unidata all EMACS="../../src/bootstrap-emacs"
make[4]: Nothing to be done for `all'.
/opt/homebrew/bin/gmkdir -p /Users/gerd/emacs/master/nextstep/Emacs.app/Contents/MacOS
cp -f ../src/emacs /Users/gerd/emacs/master/nextstep/Emacs.app/Contents/MacOS/Emacs
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C lisp all
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../leim all EMACS="../src/emacs"
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../admin/grammars all EMACS="../../src/emacs"
make[2]: Nothing to be done for `all'.
make[2]: Nothing to be done for `all'.
GEN autoloads
make[2]: Nothing to be done for `compile-targets'.
make[2]: `org.texi' is up to date.
make[2]: `modus-themes.texi' is up to date.
make[2]: Nothing to be done for `generate-ja-dic'.
make[2]: Nothing to be done for `compile-targets'.
INFO Scraping files for loaddefs...
INFO Scraping files for loaddefs...done
GEN loaddefs.el
ELC loaddefs.elc
ELC textmodes/conf-mode.elc
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C doc/misc info
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C src
GEN ../../info/tramp.info
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../admin/charsets all
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../admin/unidata charscript.el
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../admin/unidata emoji-zwj.el
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../admin/charsets cp51932.el
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../admin/charsets eucjp-ms.el
make[2]: Nothing to be done for `cp51932.el'.
make[2]: Nothing to be done for `eucjp-ms.el'.
make[2]: Nothing to be done for `charscript.el'.
make[2]: Nothing to be done for `emoji-zwj.el'.
make[2]: Nothing to be done for `all'.
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../admin/unidata all EMACS="../../src/bootstrap-emacs"
make[2]: Nothing to be done for `all'.
rm -f emacs && cp -f temacs emacs
LC_ALL=C ./temacs -batch -l loadup --temacs=pdump \
--bin-dest --eln-dest
Loading loadup.el (source)...
Dump mode: pdump
Using load-path (/Users/gerd/emacs/master/lisp)
Loading emacs-lisp/debug-early (native compiled elisp)...
Loading emacs-lisp/byte-run (native compiled elisp)...
Loading emacs-lisp/backquote (native compiled elisp)...
Loading subr (native compiled elisp)...
Loading keymap (native compiled elisp)...
Loading version (native compiled elisp)...
Loading widget (native compiled elisp)...
Loading custom (native compiled elisp)...
Loading emacs-lisp/map-ynp (native compiled elisp)...
Loading international/mule (native compiled elisp)...
Loading international/mule-conf (native compiled elisp)...
Loading env (native compiled elisp)...
Loading format (native compiled elisp)...
Loading bindings (native compiled elisp)...
Loading window (native compiled elisp)...
Loading files (native compiled elisp)...
Loading emacs-lisp/macroexp (native compiled elisp)...
Loading cus-face (native compiled elisp)...
Loading faces (native compiled elisp)...
Loading loaddefs...
Loading button (native compiled elisp)...
Loading emacs-lisp/cl-preloaded (native compiled elisp)...
Loading emacs-lisp/oclosure (native compiled elisp)...
Loading obarray (native compiled elisp)...
Loading abbrev (native compiled elisp)...
Loading help (native compiled elisp)...
Loading jka-cmpr-hook (native compiled elisp)...
Loading epa-hook (native compiled elisp)...
Loading international/mule-cmds (native compiled elisp)...
Loading case-table (native compiled elisp)...
Loading international/charprop.el (source)...
Loading international/characters (native compiled elisp)...
Loading international/charscript (native compiled elisp)...
Loading international/emoji-zwj (native compiled elisp)...
Loading composite (native compiled elisp)...
Loading language/chinese (native compiled elisp)...
Loading language/cyrillic (native compiled elisp)...
Loading language/indian (native compiled elisp)...
Loading language/sinhala (native compiled elisp)...
Loading language/english (native compiled elisp)...
Loading language/ethiopic (native compiled elisp)...
Loading language/european (native compiled elisp)...
Loading language/czech (native compiled elisp)...
Loading language/slovak (native compiled elisp)...
Loading language/romanian (native compiled elisp)...
Loading language/greek (native compiled elisp)...
Loading language/hebrew (native compiled elisp)...
Loading international/cp51932 (native compiled elisp)...
Loading international/eucjp-ms (native compiled elisp)...
Loading language/japanese (native compiled elisp)...
Loading language/korean (native compiled elisp)...
Loading language/lao (native compiled elisp)...
Loading language/tai-viet (native compiled elisp)...
Loading language/thai (native compiled elisp)...
Loading language/tibetan (native compiled elisp)...
Loading language/vietnamese (native compiled elisp)...
Loading language/misc-lang (native compiled elisp)...
Loading language/utf-8-lang (native compiled elisp)...
Loading language/georgian (native compiled elisp)...
Loading language/khmer (native compiled elisp)...
Loading language/burmese (native compiled elisp)...
Loading language/cham (native compiled elisp)...
Loading language/philippine (native compiled elisp)...
Loading language/indonesian (native compiled elisp)...
Loading indent (native compiled elisp)...
Loading emacs-lisp/cl-generic (native compiled elisp)...
Loading simple (native compiled elisp)...
Loading emacs-lisp/seq (native compiled elisp)...
Loading emacs-lisp/nadvice (native compiled elisp)...
Loading minibuffer (native compiled elisp)...
Loading frame (native compiled elisp)...
Loading startup (native compiled elisp)...
Loading term/tty-colors (native compiled elisp)...
Loading font-core (native compiled elisp)...
Loading emacs-lisp/syntax (native compiled elisp)...
Loading font-lock (native compiled elisp)...
Loading jit-lock (native compiled elisp)...
Loading mouse (native compiled elisp)...
Loading scroll-bar (native compiled elisp)...
Loading select (native compiled elisp)...
Loading emacs-lisp/timer (native compiled elisp)...
Loading emacs-lisp/easymenu (native compiled elisp)...
Loading isearch (native compiled elisp)...
Loading rfn-eshadow (native compiled elisp)...
Loading menu-bar (native compiled elisp)...
Loading tab-bar (native compiled elisp)...
Loading emacs-lisp/lisp (native compiled elisp)...
Loading textmodes/page (native compiled elisp)...
Loading register (native compiled elisp)...
Loading textmodes/paragraphs (native compiled elisp)...
Loading progmodes/prog-mode (native compiled elisp)...
Loading emacs-lisp/lisp-mode (native compiled elisp)...
Loading textmodes/text-mode (native compiled elisp)...
Loading textmodes/fill (native compiled elisp)...
Loading newcomment (native compiled elisp)...
Loading replace (native compiled elisp)...
Loading emacs-lisp/tabulated-list (native compiled elisp)...
Loading buff-menu (native compiled elisp)...
Loading fringe (native compiled elisp)...
Loading emacs-lisp/regexp-opt (native compiled elisp)...
Loading image (native compiled elisp)...
Loading international/fontset (native compiled elisp)...
Loading dnd (native compiled elisp)...
Loading tool-bar (native compiled elisp)...
Loading term/common-win (native compiled elisp)...
Loading international/mule-util (native compiled elisp)...
Loading international/ucs-normalize (native compiled elisp)...
Loading term/ns-win (native compiled elisp)...
Loading mwheel (native compiled elisp)...
Loading progmodes/elisp-mode (native compiled elisp)...
Loading emacs-lisp/float-sup (native compiled elisp)...
Loading vc/vc-hooks (native compiled elisp)...
Loading vc/ediff-hook (native compiled elisp)...
Loading uniquify (native compiled elisp)...
Loading electric (native compiled elisp)...
Loading paren (native compiled elisp)...
Loading emacs-lisp/shorthands (native compiled elisp)...
Loading emacs-lisp/eldoc (native compiled elisp)...
Loading cus-start (native compiled elisp)...
Loading tooltip (native compiled elisp)...
Loading international/iso-transl (native compiled elisp)...
Loading leim/leim-list.el (source)...
Loading emacs-lisp/rmc (native compiled elisp)...
Waiting for git...
Waiting for git...
Finding pointers to doc strings...
Finding pointers to doc strings...done
Pure-hashed: 14904 strings, 1757 vectors, 46342 conses, 1091 bytecodes, 348 others
Dumping under the name emacs.pdmp
Dumping fingerprint: c25325106c23d6c52dba3bb9f72bade38e80e766a4daa62deaf35ba3fa5d2295
Error: error ("Trying to dump non fixed-up eln file
")
(require cl-print) while preparing to dump
make[1]: *** [emacs.pdmp] Error 255
make: *** [src-depending-on-lisp] Error 2
Compilation exited abnormally with code 2 at Sat Aug 20 14:14:32
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-20 12:55 bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file" Gerd Möllmann
@ 2022-08-20 13:07 ` Lars Ingebrigtsen
2022-08-20 13:12 ` Gerd Möllmann
2022-08-20 13:18 ` Lars Ingebrigtsen
0 siblings, 2 replies; 41+ messages in thread
From: Lars Ingebrigtsen @ 2022-08-20 13:07 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: 57309, Andrea Corallo
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> I did a git pull and build from scratch this morning at about 8:44,
> everyting ok. Pulled again from git master now, new HEAD is
> 07c04da01016cd81e064a06b2449892eff7c8da0 and did a meke -j8.
I guess this is related to 842c641c57 (and subsequent changes). I'm
seeing the same but in other files, like:
(require cl-print) while preparing to dump
Error: error ("Trying to dump non fixed-up eln file
")
A bootstrap makes this go away, apparently.
I've added Andrea to the CCs.
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-20 13:07 ` Lars Ingebrigtsen
@ 2022-08-20 13:12 ` Gerd Möllmann
2022-08-20 13:18 ` Lars Ingebrigtsen
1 sibling, 0 replies; 41+ messages in thread
From: Gerd Möllmann @ 2022-08-20 13:12 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 57309, Andrea Corallo
Lars Ingebrigtsen <larsi@gnus.org> writes:
W> (require cl-print) while preparing to dump
> Error: error ("Trying to dump non fixed-up eln file
> ")
Yes, I have that too, only the other way around, that is for the "trying
to" then the "reauire...".
> A bootstrap makes this go away, apparently.
>
> I've added Andrea to the CCs.
Thanks. I'll leave this untouched here.
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-20 13:07 ` Lars Ingebrigtsen
2022-08-20 13:12 ` Gerd Möllmann
@ 2022-08-20 13:18 ` Lars Ingebrigtsen
2022-08-20 13:21 ` Gerd Möllmann
1 sibling, 1 reply; 41+ messages in thread
From: Lars Ingebrigtsen @ 2022-08-20 13:18 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: 57309, Andrea Corallo
Lars Ingebrigtsen <larsi@gnus.org> writes:
> A bootstrap makes this go away, apparently.
Hm. Just saying "make" again made it go away? (I tried in a different
directory I had here.)
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-20 13:18 ` Lars Ingebrigtsen
@ 2022-08-20 13:21 ` Gerd Möllmann
2022-08-20 13:26 ` Eli Zaretskii
2022-08-20 13:27 ` Lars Ingebrigtsen
0 siblings, 2 replies; 41+ messages in thread
From: Gerd Möllmann @ 2022-08-20 13:21 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 57309, Andrea Corallo
Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> A bootstrap makes this go away, apparently.
>
> Hm. Just saying "make" again made it go away? (I tried in a different
> directory I had here.)
Can you tell what that make produced?
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-20 13:21 ` Gerd Möllmann
@ 2022-08-20 13:26 ` Eli Zaretskii
2022-08-20 13:29 ` Lars Ingebrigtsen
2022-08-20 13:27 ` Lars Ingebrigtsen
1 sibling, 1 reply; 41+ messages in thread
From: Eli Zaretskii @ 2022-08-20 13:26 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: larsi, 57309, akrl
> Cc: 57309@debbugs.gnu.org, Andrea Corallo <akrl@sdf.org>
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Sat, 20 Aug 2022 15:21:47 +0200
>
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> >
> > Lars Ingebrigtsen <larsi@gnus.org> writes:
> >
> >> A bootstrap makes this go away, apparently.
> >
> > Hm. Just saying "make" again made it go away? (I tried in a different
> > directory I had here.)
>
> Can you tell what that make produced?
I'd bet it regenerated the *.eln files.
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-20 13:21 ` Gerd Möllmann
2022-08-20 13:26 ` Eli Zaretskii
@ 2022-08-20 13:27 ` Lars Ingebrigtsen
2022-08-20 13:37 ` Gerd Möllmann
1 sibling, 1 reply; 41+ messages in thread
From: Lars Ingebrigtsen @ 2022-08-20 13:27 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: 57309, Andrea Corallo
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> Can you tell what that make produced?
Based on the timestamps, apparently it just re-dumped itself:
$ ls -lt src | head
-rw-rw-r-- 1 larsi larsi 13447624 Aug 20 15:16 bootstrap-emacs.pdmp
-rw-rw-r-- 2 larsi larsi 13447624 Aug 20 15:16 emacs-29.0.50.6.pdmp
-rw-rw-r-- 2 larsi larsi 13447624 Aug 20 15:16 emacs.pdmp
-rwxrwxr-x 2 larsi larsi 29613024 Aug 20 15:16 emacs
-rwxrwxr-x 2 larsi larsi 29613024 Aug 20 15:16 emacs-29.0.50.6
-rw-rw-r-- 1 larsi larsi 13447624 Aug 20 15:05 emacs-29.0.50.5.pdmp
No files in lisp changed.
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-20 13:26 ` Eli Zaretskii
@ 2022-08-20 13:29 ` Lars Ingebrigtsen
2022-08-20 13:45 ` Eli Zaretskii
0 siblings, 1 reply; 41+ messages in thread
From: Lars Ingebrigtsen @ 2022-08-20 13:29 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Gerd Möllmann, 57309, akrl
Eli Zaretskii <eliz@gnu.org> writes:
> I'd bet it regenerated the *.eln files.
No, doesn't look like it:
larsi@joga:~/src/emacs/nativecomp$ ls -lt native-lisp/29.0.50-107b8711/ | head
total 2020
-rwxrwxr-x 1 larsi larsi 18216 Aug 20 15:05 comp-test-funcs-dyn-c1337da0-37b66b75.eln
-rwxrwxr-x 1 larsi larsi 91240 Aug 20 15:05 comp-test-funcs-9c4ce35e-f58ebfa6.eln
-rwxrwxr-x 1 larsi larsi 16160 Aug 20 15:05 subr--trampoline-782d64656c6574652d77696e646f772d70726f7065727479_x_delete_window_property_0.eln
-rwxrwxr-x 1 larsi larsi 16160 Aug 20 15:05 subr--trampoline-782d6368616e67652d77696e646f772d70726f7065727479_x_change_window_property_0.eln
(The .pdmp file has a timestamp of 15:16.)
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-20 13:27 ` Lars Ingebrigtsen
@ 2022-08-20 13:37 ` Gerd Möllmann
2022-08-20 14:32 ` Gerd Möllmann
2022-08-21 11:57 ` Lars Ingebrigtsen
0 siblings, 2 replies; 41+ messages in thread
From: Gerd Möllmann @ 2022-08-20 13:37 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 57309, Andrea Corallo
Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Can you tell what that make produced?
>
> Based on the timestamps, apparently it just re-dumped itself:
Strange. I could reproduce this at least twice in a row with lldb by
running it on './temacs -batch -l loadup --temacs=pdump --bin-dest
--eln-dest'. (And now I'm not daring to leave the debugger again :-).
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-20 13:29 ` Lars Ingebrigtsen
@ 2022-08-20 13:45 ` Eli Zaretskii
2022-08-21 11:55 ` Lars Ingebrigtsen
0 siblings, 1 reply; 41+ messages in thread
From: Eli Zaretskii @ 2022-08-20 13:45 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: gerd.moellmann, 57309, akrl
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
> 57309@debbugs.gnu.org,
> akrl@sdf.org
> Date: Sat, 20 Aug 2022 15:29:06 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > I'd bet it regenerated the *.eln files.
>
> No, doesn't look like it:
>
> larsi@joga:~/src/emacs/nativecomp$ ls -lt native-lisp/29.0.50-107b8711/ | head
> total 2020
> -rwxrwxr-x 1 larsi larsi 18216 Aug 20 15:05 comp-test-funcs-dyn-c1337da0-37b66b75.eln
> -rwxrwxr-x 1 larsi larsi 91240 Aug 20 15:05 comp-test-funcs-9c4ce35e-f58ebfa6.eln
> -rwxrwxr-x 1 larsi larsi 16160 Aug 20 15:05 subr--trampoline-782d64656c6574652d77696e646f772d70726f7065727479_x_delete_window_property_0.eln
> -rwxrwxr-x 1 larsi larsi 16160 Aug 20 15:05 subr--trampoline-782d6368616e67652d77696e646f772d70726f7065727479_x_change_window_property_0.eln
The preloaded files, such as window-NNN.eln, would be in
native-lisp/29.0.50-107b8711/preloaded/. And how do you know
29.0.50-107b8711 is the correct subdirectory of native-lisp/ ? Is it
the latest (time-stamp-wise)?
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-20 13:37 ` Gerd Möllmann
@ 2022-08-20 14:32 ` Gerd Möllmann
2022-08-20 15:08 ` Gerd Möllmann
2022-08-20 15:25 ` Eli Zaretskii
2022-08-21 11:57 ` Lars Ingebrigtsen
1 sibling, 2 replies; 41+ messages in thread
From: Gerd Möllmann @ 2022-08-20 14:32 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 57309, Andrea Corallo
(lldb) p globals.f_Vcomp_loaded_comp_units_h
(Lisp_Object) $176 = 0x00000001040382b5 (struct Lisp_Hash_Table *) $181 = 0x00000001040382b0
(lldb) p *$181
(struct Lisp_Hash_Table) $182 = {
header = (size = 4611686018662313988)
weak = 0x000000000000fdb0 (struct Lisp_Symbol *) $185 = 0x00000001007d2b90
hash = 0x00000001042d10b5 (struct Lisp_Vector *) $189 = 0x00000001042d10b0
next = 0x00000001042d078d (struct Lisp_Vector *) $193 = 0x00000001042d0788
index = 0x00000001042d1605 (struct Lisp_Vector *) $197 = 0x00000001042d1600
count = 90
next_free = 90
purecopy = false
mutable = true
rehash_threshold = 0.8125
rehash_size = 0.5
key_and_value = 0x00000001042d0a9d (struct Lisp_Vector *) $201 = 0x00000001042d0a98
test = {
name = 0x00000000000060c0 (struct Lisp_Symbol *) $204 = 0x00000001007c8ea0
user_hash_function = NULL
user_cmp_function = NULL
cmpfn = 0x000000010017ed70 (temacs`cmpfn_equal at fns.c:4235)
hashfn = 0x000000010017ed9c (temacs`hashfn_equal at fns.c:4266)
}
next_weak = NULL
}
(lldb) xdebug_print $176
...lots of output...
"/Users/gerd/emacs/master/native-lisp/29_0_50-2dce7c3a/preloaded/window-0d1b8b93-274db3e2.eln" #<native compilation unit: /Users/gerd/emacs/master/native-lisp/29_0_50-2dce7c3a/preloaded/window-0d1b8b93-274db3e2.eln ((native-comp-speed . 2) (native-comp-debug . 0) (gccjit 12 1 0))>
...
I'm not 100% sure, but I interpret that as meaning that the window.eln
in question has already been loaded before, and the second attempt then
fails. Unless I misread the code of course, which is always possible.
But how that might happen escapes me ATM.
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-20 14:32 ` Gerd Möllmann
@ 2022-08-20 15:08 ` Gerd Möllmann
2022-08-21 7:03 ` Gerd Möllmann
2022-08-20 15:25 ` Eli Zaretskii
1 sibling, 1 reply; 41+ messages in thread
From: Gerd Möllmann @ 2022-08-20 15:08 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 57309, Andrea Corallo
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
> (lldb) p globals.f_Vcomp_loaded_comp_units_h
> (Lisp_Object) $176 = 0x00000001040382b5 (struct Lisp_Hash_Table *) $181 = 0x00000001040382b0
> (lldb) p *$181
> (struct Lisp_Hash_Table) $182 = {
> header = (size = 4611686018662313988)
> weak = 0x000000000000fdb0 (struct Lisp_Symbol *) $185 = 0x00000001007d2b90
> hash = 0x00000001042d10b5 (struct Lisp_Vector *) $189 = 0x00000001042d10b0
> next = 0x00000001042d078d (struct Lisp_Vector *) $193 = 0x00000001042d0788
> index = 0x00000001042d1605 (struct Lisp_Vector *) $197 = 0x00000001042d1600
> count = 90
> next_free = 90
> purecopy = false
> mutable = true
> rehash_threshold = 0.8125
> rehash_size = 0.5
> key_and_value = 0x00000001042d0a9d (struct Lisp_Vector *) $201 = 0x00000001042d0a98
> test = {
> name = 0x00000000000060c0 (struct Lisp_Symbol *) $204 = 0x00000001007c8ea0
> user_hash_function = NULL
> user_cmp_function = NULL
> cmpfn = 0x000000010017ed70 (temacs`cmpfn_equal at fns.c:4235)
> hashfn = 0x000000010017ed9c (temacs`hashfn_equal at fns.c:4266)
> }
> next_weak = NULL
> }
> (lldb) xdebug_print $176
> ...lots of output...
> "/Users/gerd/emacs/master/native-lisp/29_0_50-2dce7c3a/preloaded/window-0d1b8b93-274db3e2.eln" #<native compilation unit: /Users/gerd/emacs/master/native-lisp/29_0_50-2dce7c3a/preloaded/window-0d1b8b93-274db3e2.eln ((native-comp-speed . 2) (native-comp-debug . 0) (gccjit 12 1 0))>
> ...
>
> I'm not 100% sure, but I interpret that as meaning that the window.eln
> in question has already been loaded before, and the second attempt then
> fails. Unless I misread the code of course, which is always possible.
>
> But how that might happen escapes me ATM.
And a little bit more...
The error "trying to..." comes from dump_native_comp_unit, which is
called from dump_vectorlike, which is called from dump_object. Dumped
objects are recorded in a hashtable dump_context::objects_dumped. Now
(lldb) p ctx->objects_dumped
(Lisp_Object) $294 = 0x000000010407373d (struct Lisp_Hash_Table *) $299 = 0x0000000104073738
(lldb) expr -- hash_lookup ($299, lv, 0)
(ptrdiff_t) $300 = 2010
(lldb) p lv
(Lisp_Object) $301 = 0x00000001040d0a6d (struct Lisp_Native_Comp_Unit *) $306 = 0x00000001040d0a68
lv is the compilation unit in question which gives the error, and the
dumpcontext says it is already dumped.
So what now?
I'd say one can encounter the same Lisp_Object more than once in a dump,
in general. Shouldn't there be some check somewhere in the CU code?
Where is it? Or is this supposed not to happen? If so, how is it
ensured?
Questions over questions...
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-20 14:32 ` Gerd Möllmann
2022-08-20 15:08 ` Gerd Möllmann
@ 2022-08-20 15:25 ` Eli Zaretskii
2022-08-21 6:39 ` Gerd Möllmann
1 sibling, 1 reply; 41+ messages in thread
From: Eli Zaretskii @ 2022-08-20 15:25 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: larsi, 57309, akrl
> Cc: 57309@debbugs.gnu.org, Andrea Corallo <akrl@sdf.org>
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Sat, 20 Aug 2022 16:32:33 +0200
>
> (lldb) xdebug_print $176
> ...lots of output...
> "/Users/gerd/emacs/master/native-lisp/29_0_50-2dce7c3a/preloaded/window-0d1b8b93-274db3e2.eln" #<native compilation unit: /Users/gerd/emacs/master/native-lisp/29_0_50-2dce7c3a/preloaded/window-0d1b8b93-274db3e2.eln ((native-comp-speed . 2) (native-comp-debug . 0) (gccjit 12 1 0))>
> ...
>
> I'm not 100% sure, but I interpret that as meaning that the window.eln
> in question has already been loaded before, and the second attempt then
> fails. Unless I misread the code of course, which is always possible.
>
> But how that might happen escapes me ATM.
AFAICT, temacs didn't load window.eln, it loaded window.elc. At least
that's what I see in the loadup output: it says "Loading windows...",
and doesn't say "(native compiled Lisp)". Unless the message is
already mistaken, part of the problem.
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-20 15:25 ` Eli Zaretskii
@ 2022-08-21 6:39 ` Gerd Möllmann
2022-08-21 6:43 ` Eli Zaretskii
0 siblings, 1 reply; 41+ messages in thread
From: Gerd Möllmann @ 2022-08-21 6:39 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: larsi, 57309, akrl
Eli Zaretskii <eliz@gnu.org> writes:
> AFAICT, temacs didn't load window.eln, it loaded window.elc. At least
> that's what I see in the loadup output: it says "Loading windows...",
> and doesn't say "(native compiled Lisp)". Unless the message is
> already mistaken, part of the problem.
Was that in something Lars sent? In the *compilation* buffer I sent it
said
Loading bindings (native compiled elisp)...
Loading window (native compiled elisp)...
... more loading ...
Waiting for git...
Waiting for git...
Finding pointers to doc strings...
Finding pointers to doc strings...done
Pure-hashed: 14904 strings, 1757 vectors, 46342 conses, 1091 bytecodes, 348 others
Dumping under the name emacs.pdmp
Dumping fingerprint: c25325106c23d6c52dba3bb9f72bade38e80e766a4daa62deaf35ba3fa5d2295
Error: error ("Trying to dump non fixed-up eln file
"
If it was from Lars, maybe we have two problems, then.
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-21 6:39 ` Gerd Möllmann
@ 2022-08-21 6:43 ` Eli Zaretskii
2022-08-21 6:47 ` Gerd Möllmann
0 siblings, 1 reply; 41+ messages in thread
From: Eli Zaretskii @ 2022-08-21 6:43 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: larsi, 57309, akrl
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: larsi@gnus.org, 57309@debbugs.gnu.org, akrl@sdf.org
> Date: Sun, 21 Aug 2022 08:39:00 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > AFAICT, temacs didn't load window.eln, it loaded window.elc. At least
> > that's what I see in the loadup output: it says "Loading windows...",
> > and doesn't say "(native compiled Lisp)". Unless the message is
> > already mistaken, part of the problem.
>
> Was that in something Lars sent?
No, I saw it in my own build (which failed in the same way).
> In the *compilation* buffer I sent it said
>
> Loading bindings (native compiled elisp)...
> Loading window (native compiled elisp)...
That's not what I saw.
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-21 6:43 ` Eli Zaretskii
@ 2022-08-21 6:47 ` Gerd Möllmann
2022-08-21 7:03 ` Eli Zaretskii
0 siblings, 1 reply; 41+ messages in thread
From: Gerd Möllmann @ 2022-08-21 6:47 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: larsi, 57309, akrl
Eli Zaretskii <eliz@gnu.org> writes:
>> Loading bindings (native compiled elisp)...
>> Loading window (native compiled elisp)...
>
> That's not what I saw.
I don't think so because the error doesn't tell, but could you perhaps
deternube if it was also window*.eln that lead to the error?
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-21 6:47 ` Gerd Möllmann
@ 2022-08-21 7:03 ` Eli Zaretskii
2022-08-21 7:13 ` Gerd Möllmann
0 siblings, 1 reply; 41+ messages in thread
From: Eli Zaretskii @ 2022-08-21 7:03 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: larsi, 57309, akrl
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: larsi@gnus.org, 57309@debbugs.gnu.org, akrl@sdf.org
> Date: Sun, 21 Aug 2022 08:47:59 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> Loading bindings (native compiled elisp)...
> >> Loading window (native compiled elisp)...
> >
> > That's not what I saw.
>
> I don't think so because the error doesn't tell, but could you perhaps
> deternube if it was also window*.eln that lead to the error?
Yes, the error message and the data I saw under GDB are the same as
you did.
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-20 15:08 ` Gerd Möllmann
@ 2022-08-21 7:03 ` Gerd Möllmann
2022-08-21 8:50 ` Gerd Möllmann
0 siblings, 1 reply; 41+ messages in thread
From: Gerd Möllmann @ 2022-08-21 7:03 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 57309, Andrea Corallo
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> And a little bit more...
>
> The error "trying to..." comes from dump_native_comp_unit, which is
> called from dump_vectorlike, which is called from dump_object. Dumped
> objects are recorded in a hashtable dump_context::objects_dumped. Now
>
> (lldb) p ctx->objects_dumped
> (Lisp_Object) $294 = 0x000000010407373d (struct Lisp_Hash_Table *) $299 = 0x0000000104073738
> (lldb) expr -- hash_lookup ($299, lv, 0)
> (ptrdiff_t) $300 = 2010
> (lldb) p lv
> (Lisp_Object) $301 = 0x00000001040d0a6d (struct Lisp_Native_Comp_Unit *) $306 = 0x00000001040d0a68
>
> lv is the compilation unit in question which gives the error, and the
> dumpcontext says it is already dumped.
>
> So what now?
>
> I'd say one can encounter the same Lisp_Object more than once in a dump,
> in general. Shouldn't there be some check somewhere in the CU code?
> Where is it? Or is this supposed not to happen? If so, how is it
> ensured?
>
> Questions over questions...
I think I've at least found where recognizing already dumped objects
happens. It's here:
static dump_off
dump_object (struct dump_context *ctx, Lisp_Object object)
{
#if CHECK_STRUCTS && !defined (HASH_Lisp_Type_45F0582FD7)
# error "Lisp_Type changed. See CHECK_STRUCTS comment in config.h."
#endif
eassert (!EQ (object, dead_object ()));
dump_off offset = dump_recall_object (ctx, object);
if (offset > 0)
return offset; /* Object already dumped. */
dump_recall_object should have returned an offset > 0 the second time
the window.eln compilation unit was to be dumped. (I'm almost 100% sure
that that's was is happening here because I can find it in the
objects_dumped hash table.)
Only, I don't see what is going wrong after that. Maybe it is something
following the code above. The flags in dump_context for example, I
don't really understand. Or is it that dump_object_emacs_ptr returns
NULL, and something is happening then, or not happening?
Hm.
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-21 7:03 ` Eli Zaretskii
@ 2022-08-21 7:13 ` Gerd Möllmann
0 siblings, 0 replies; 41+ messages in thread
From: Gerd Möllmann @ 2022-08-21 7:13 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: larsi, 57309, akrl
Eli Zaretskii <eliz@gnu.org> writes:
>> I don't think so because the error doesn't tell, but could you perhaps
>> deternube if it was also window*.eln that lead to the error?
>
> Yes, the error message and the data I saw under GDB are the same as
> you did.
Thanks. Strange.
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-21 7:03 ` Gerd Möllmann
@ 2022-08-21 8:50 ` Gerd Möllmann
2022-08-21 10:13 ` Eli Zaretskii
0 siblings, 1 reply; 41+ messages in thread
From: Gerd Möllmann @ 2022-08-21 8:50 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 57309, Andrea Corallo
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>> And a little bit more...
>>
>> The error "trying to..." comes from dump_native_comp_unit, which is
>> called from dump_vectorlike, which is called from dump_object. Dumped
>> objects are recorded in a hashtable dump_context::objects_dumped. Now
>>
>> (lldb) p ctx->objects_dumped
>> (Lisp_Object) $294 = 0x000000010407373d (struct Lisp_Hash_Table *) $299 = 0x0000000104073738
>> (lldb) expr -- hash_lookup ($299, lv, 0)
>> (ptrdiff_t) $300 = 2010
>> (lldb) p lv
>> (Lisp_Object) $301 = 0x00000001040d0a6d (struct Lisp_Native_Comp_Unit *) $306 = 0x00000001040d0a68
>>
>> lv is the compilation unit in question which gives the error, and the
>> dumpcontext says it is already dumped.
>>
Sorry for following up again to myself, but I haven't lost the hope that
someone in the know chimes in at some point :-).
When I print the value that the window.eln compilation unit has in
objects_dumped
(lldb) expr -- $299->key_and_value
(Lisp_Object) $317 = 0x000000011004800d (struct Lisp_Vector *) $321 = 0x0000000110048008
(lldb) expr -- $321->contents [2*2010 + 1]
(Lisp_Object) $322 = 0xfffffffffffffffe (struct Lisp_Cons *) $324 = 0xfffffffffffffff8
(lldb) xdebug_print $321->contents [2*2010 + 1]
-1
We see (a) my lldb support has a bug (shit), and (b) that the value is
-1, which is DUMP_OBJECT_ON_NORMAL_QUEUE.
And when I go a frame up in the callstack, I see indeed
frame #5: 0x000000010014cc24 temacs`dump_drain_normal_queue(ctx=0x000000016fdfe300) at pdumper.c:3985:5 [opt]
3982 dump_drain_normal_queue (struct dump_context *ctx)
3983 {
3984 while (!dump_queue_empty_p (&ctx->dump_queue))
-> 3985 dump_object (ctx, dump_queue_dequeue (&ctx->dump_queue, ctx->offset));
3986 }
Another frame up
frame #6: 0x000000010014b514 temacs`Fdump_emacs_portable(filename=<unavailable>, track_referrers=<unavailable>) at pdumper.c:4175:7 [opt]
4172 {
4173 dump_drain_deferred_hash_tables (ctx);
4174 dump_drain_deferred_symbols (ctx);
-> 4175 dump_drain_normal_queue (ctx);
4176 }
So, I think what happens here is this:
Window.eln's compilation unit gets dumped normally the first time
around. But it also is put on the dump_context::dump_queue for some
reason. Add when the queue is processed, boom...
Hm again.
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-21 8:50 ` Gerd Möllmann
@ 2022-08-21 10:13 ` Eli Zaretskii
2022-08-21 10:45 ` Gerd Möllmann
0 siblings, 1 reply; 41+ messages in thread
From: Eli Zaretskii @ 2022-08-21 10:13 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: larsi, 57309, akrl
> Cc: 57309@debbugs.gnu.org, Andrea Corallo <akrl@sdf.org>
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Sun, 21 Aug 2022 10:50:11 +0200
>
> So, I think what happens here is this:
>
> Window.eln's compilation unit gets dumped normally the first time
> around. But it also is put on the dump_context::dump_queue for some
> reason. Add when the queue is processed, boom...
>
> Hm again.
I've removed src/emacs and src/bootstrap-emacs, and said "make". That
succeeded, but most of the preloaded files were loaded as *.elc. Then
I touch'ed every .el file that is preloaded, and said "make" again.
This ELC+ELN-compiled all of them, and then successfully loaded and
dumped them.
Not sure what that means, but maybe try the same recipe?
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-21 10:13 ` Eli Zaretskii
@ 2022-08-21 10:45 ` Gerd Möllmann
2022-08-21 10:58 ` Eli Zaretskii
0 siblings, 1 reply; 41+ messages in thread
From: Gerd Möllmann @ 2022-08-21 10:45 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: larsi, 57309, akrl
Eli Zaretskii <eliz@gnu.org> writes:
> I've removed src/emacs and src/bootstrap-emacs, and said "make". That
> succeeded, but most of the preloaded files were loaded as *.elc. Then
> I touch'ed every .el file that is preloaded, and said "make" again.
> This ELC+ELN-compiled all of them, and then successfully loaded and
> dumped them.
>
> Not sure what that means, but maybe try the same recipe?
That it succeeds is kind of what I'm afraid of :-).
I think Lars mentioned that a simple second make run made things work
for him, and now I'm afraid if I leave the debugger or touch anything, I
won't be able to reproduce the error again.
BTW, I think I've seen the same bug with the last change to Makefile.in,
only with a different error message "...incoherent something...", where
Lars mentioned he had seen that sort of error ca. once per month or so.
Something is really fishy here. It reminds me a bit of situtations when
people don't take conservative stack marking into account, and then
mistakenly assume that objects will be removed during the next GC after
removing the last reference to it from their Lisp data structure. Which
is mistaken because of disingeneous references from the C stack. But I
also don't know how that would come into play here.
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-21 10:45 ` Gerd Möllmann
@ 2022-08-21 10:58 ` Eli Zaretskii
2022-08-22 8:43 ` Andrea Corallo
0 siblings, 1 reply; 41+ messages in thread
From: Eli Zaretskii @ 2022-08-21 10:58 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: larsi, 57309, akrl
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: larsi@gnus.org, 57309@debbugs.gnu.org, akrl@sdf.org
> Date: Sun, 21 Aug 2022 12:45:05 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > I've removed src/emacs and src/bootstrap-emacs, and said "make". That
> > succeeded, but most of the preloaded files were loaded as *.elc. Then
> > I touch'ed every .el file that is preloaded, and said "make" again.
> > This ELC+ELN-compiled all of them, and then successfully loaded and
> > dumped them.
> >
> > Not sure what that means, but maybe try the same recipe?
>
> That it succeeds is kind of what I'm afraid of :-).
>
> I think Lars mentioned that a simple second make run made things work
> for him, and now I'm afraid if I leave the debugger or touch anything, I
> won't be able to reproduce the error again.
>
> BTW, I think I've seen the same bug with the last change to Makefile.in,
> only with a different error message "...incoherent something...", where
> Lars mentioned he had seen that sort of error ca. once per month or so.
>
> Something is really fishy here.
The *.eln files aren't regenerated unless the corresponding *.el files
are newer than their *.elc files. This is a basic snafu we are living
with since the development of Emacs 28, and it still isn't resolved.
This happens even when Emacs changes in a way that requires a new
subdirectory under native-lisp/, which is a clear sign that the *.eln
files need to be regenerated.
So yes, something is definitely "fishy". I suspect that the changes
Andrea did recently required a bump in the ABI_VERSION value, which
would then prevent Emacs from trying to load the old *.eln files. But
maybe I'm missing something. I hope Andrea chimes in soon.
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-20 13:45 ` Eli Zaretskii
@ 2022-08-21 11:55 ` Lars Ingebrigtsen
0 siblings, 0 replies; 41+ messages in thread
From: Lars Ingebrigtsen @ 2022-08-21 11:55 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gerd.moellmann, 57309, akrl
Eli Zaretskii <eliz@gnu.org> writes:
> The preloaded files, such as window-NNN.eln, would be in
> native-lisp/29.0.50-107b8711/preloaded/. And how do you know
> 29.0.50-107b8711 is the correct subdirectory of native-lisp/ ? Is it
> the latest (time-stamp-wise)?
Yes, it's the latest.
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-20 13:37 ` Gerd Möllmann
2022-08-20 14:32 ` Gerd Möllmann
@ 2022-08-21 11:57 ` Lars Ingebrigtsen
2022-08-21 12:28 ` Gerd Möllmann
1 sibling, 1 reply; 41+ messages in thread
From: Lars Ingebrigtsen @ 2022-08-21 11:57 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: 57309, Andrea Corallo
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> Strange. I could reproduce this at least twice in a row with lldb by
> running it on './temacs -batch -l loadup --temacs=pdump --bin-dest
> --eln-dest'. (And now I'm not daring to leave the debugger again :-).
Perhaps just "cp -a" the entire build tree over somewhere else, and then
say "make" there in the copy and see what happens?
(I've got dozens of build trees on a couple machines to try out stuff
like this when things break in mysterious ways, but I unfortunately
forgot to cp my nativecomp build tree before building this time.)
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-21 11:57 ` Lars Ingebrigtsen
@ 2022-08-21 12:28 ` Gerd Möllmann
2022-08-21 12:36 ` Eli Zaretskii
0 siblings, 1 reply; 41+ messages in thread
From: Gerd Möllmann @ 2022-08-21 12:28 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 57309, Andrea Corallo
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Perhaps just "cp -a" the entire build tree over somewhere else, and then
> say "make" there in the copy and see what happens?
Thanks, good idea, and it worked!
In the new lldb session I see that the very first time
dump_native_comp_unit is called, it's aöready failing:
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x00000001001526cc temacs`dump_native_comp_unit(ctx=0x000000016fdfe300, comp_u=0x0000000107089a68) at pdumper.c:2913:23 [opt]
2910 dump_native_comp_unit (struct dump_context *ctx,
2911 struct Lisp_Native_Comp_Unit *comp_u)
2912 {
-> 2913 if (!CONSP (comp_u->file))
2914 error ("Trying to dump non fixed-up eln file\n");
2915
2916 /* Have function documentation always lazy loaded to optimize load-time. */
Target 0: (temacs) stopped.
(lldb) p comp_u->file
(Lisp_Object) $0 = 0x0000000103911394 (struct Lisp_String *) $2 = 0x0000000103911390
(lldb) p *$2
(struct Lisp_String) $3 = {
u = {
s = {
size = 93
size_byte = -1
intervals = NULL
data = 0x000000011a0158b8 "/Users/gerd/emacs/master2/native-lisp/29_0_50-2dce7c3a/preloaded/window-0d1b8b93-274db3e2.eln"
}
next = 0x000000000000005d
gcaligned = ']'
}
}
The backtrace is identical to the other debugger session.
Which means that the window.eln cu hasn't been dumped before, which
means what?
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-21 12:28 ` Gerd Möllmann
@ 2022-08-21 12:36 ` Eli Zaretskii
2022-08-21 12:46 ` Gerd Möllmann
0 siblings, 1 reply; 41+ messages in thread
From: Eli Zaretskii @ 2022-08-21 12:36 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: larsi, 57309, akrl
> Cc: 57309@debbugs.gnu.org, Andrea Corallo <akrl@sdf.org>
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Sun, 21 Aug 2022 14:28:58 +0200
>
> Which means that the window.eln cu hasn't been dumped before, which
> means what?
Did temacs succeed in loading window-0d1b8b93-274db3e2.eln?
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-21 12:36 ` Eli Zaretskii
@ 2022-08-21 12:46 ` Gerd Möllmann
2022-08-21 12:55 ` Eli Zaretskii
0 siblings, 1 reply; 41+ messages in thread
From: Gerd Möllmann @ 2022-08-21 12:46 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: larsi, 57309, akrl
Eli Zaretskii <eliz@gnu.org> writes:
>
>> Cc: 57309@debbugs.gnu.org, Andrea Corallo <akrl@sdf.org>
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Date: Sun, 21 Aug 2022 14:28:58 +0200
>>
>> Which means that the window.eln cu hasn't been dumped before, which
>> means what?
>
> Did temacs succeed in loading window-0d1b8b93-274db3e2.eln?
Looks like it. After a debugger restart, I can see it being loaded from
loadup
frame #3: 0x00000001001c1154 temacs`Fnative_elisp_load(filename=(struct Lisp_String *) $262 = 0x0000000103913a90, late_load=(struct Lisp_Symbol *) $265 = 0x00000001007c2de0) at comp.c:5547:3 [opt]
5544 LATE_LOAD has to be non-nil when loading for deferred compilation. */)
5545 (Lisp_Object filename, Lisp_Object late_load)
5546 {
-> 5547 CHECK_STRING (filename);
5548 if (NILP (Ffile_exists_p (filename)))
5549 xsignal2 (Qnative_lisp_load_failed, build_string ("file does not exists"),
5550 filename);
(lldb) p *$268
(struct Lisp_String) $269 = {
u = {
s = {
size = 93
size_byte = -1
intervals = NULL
data = 0x00000001040cca58 "/Users/gerd/emacs/master2/native-lisp/29_0_50-2dce7c3a/preloaded/window-0d1b8b93-274db3e2.eln"
}
next = 0x000000000000005d
gcaligned = ']'
}
and there's no error loading it.
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-21 12:46 ` Gerd Möllmann
@ 2022-08-21 12:55 ` Eli Zaretskii
2022-08-21 13:08 ` Gerd Möllmann
2022-08-21 13:11 ` Gerd Möllmann
0 siblings, 2 replies; 41+ messages in thread
From: Eli Zaretskii @ 2022-08-21 12:55 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: larsi, 57309, akrl
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: larsi@gnus.org, 57309@debbugs.gnu.org, akrl@sdf.org
> Date: Sun, 21 Aug 2022 14:46:32 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > Did temacs succeed in loading window-0d1b8b93-274db3e2.eln?
>
> Looks like it. After a debugger restart, I can see it being loaded from
> loadup
>
> frame #3: 0x00000001001c1154 temacs`Fnative_elisp_load(filename=(struct Lisp_String *) $262 = 0x0000000103913a90, late_load=(struct Lisp_Symbol *) $265 = 0x00000001007c2de0) at comp.c:5547:3 [opt]
> 5544 LATE_LOAD has to be non-nil when loading for deferred compilation. */)
> 5545 (Lisp_Object filename, Lisp_Object late_load)
> 5546 {
> -> 5547 CHECK_STRING (filename);
> 5548 if (NILP (Ffile_exists_p (filename)))
> 5549 xsignal2 (Qnative_lisp_load_failed, build_string ("file does not exists"),
> 5550 filename);
>
> (lldb) p *$268
> (struct Lisp_String) $269 = {
> u = {
> s = {
> size = 93
> size_byte = -1
> intervals = NULL
> data = 0x00000001040cca58 "/Users/gerd/emacs/master2/native-lisp/29_0_50-2dce7c3a/preloaded/window-0d1b8b93-274db3e2.eln"
> }
> next = 0x000000000000005d
> gcaligned = ']'
> }
>
> and there's no error loading it.
Does LLDB have the equivalent of "info share" command? If so, do you
see window-0d1b8b93-274db3e2.eln in the list of loaded shared
libraries after the above?
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-21 12:55 ` Eli Zaretskii
@ 2022-08-21 13:08 ` Gerd Möllmann
2022-08-21 13:19 ` Eli Zaretskii
2022-08-21 13:11 ` Gerd Möllmann
1 sibling, 1 reply; 41+ messages in thread
From: Gerd Möllmann @ 2022-08-21 13:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: larsi, 57309, akrl
Eli Zaretskii <eliz@gnu.org> writes:
> Does LLDB have the equivalent of "info share" command? If so, do you
> see window-0d1b8b93-274db3e2.eln in the list of loaded shared
> libraries after the above?
My cheat sheet says that's 'image list' in lldb. And it's there
[317] 41B40204-1F2E-3149-984B-D3FB2ED81504 0x00000001029c0000 /Users/gerd/emacs/master2/native-lisp/29_0_50-2dce7c3a/preloaded/format-c5b23b0d-d01f10d8.eln
[318] F6785E28-B011-365D-8962-17A45A7DE211 0x0000000102d04000 /Users/gerd/emacs/master2/native-lisp/29_0_50-2dce7c3a/preloaded/bindings-d30713c5-e2748f1c.eln
[319] FDDCB191-1E84-340C-9CDD-F269DB68737F 0x0000000104920000 /Users/gerd/emacs/master2/native-lisp/29_0_50-2dce7c3a/preloaded/window-0d1b8b93-274db3e2.eln
[320] 324D97E7-B153-30E2-9303-8F76E32A3ABC 0x0000000104888000 /Users/gerd/emacs/master2/native-lisp/29_0_50-2dce7c3a/preloaded/files-1e8937b2-ae59da5e.eln
[321] C4D48829-21CC-3E26-9EFB-6E51B9CF3E1B 0x0000000102d20000 /Users/gerd/emacs/master2/native-lisp/29_0_50-2dce7c3a/preloaded/macroexp-2c3e1495-553e0f8f.eln
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-21 12:55 ` Eli Zaretskii
2022-08-21 13:08 ` Gerd Möllmann
@ 2022-08-21 13:11 ` Gerd Möllmann
2022-08-21 13:14 ` Gerd Möllmann
1 sibling, 1 reply; 41+ messages in thread
From: Gerd Möllmann @ 2022-08-21 13:11 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: larsi, 57309, akrl
Eli Zaretskii <eliz@gnu.org> writes:
> Does LLDB have the equivalent of "info share" command? If so, do you
> see window-0d1b8b93-274db3e2.eln in the list of loaded shared
> libraries after the above?
I did something else also. With a breakpoint on
4: name = 'Fnative_comp_unit_set_file', locations = 1, resolved = 1, hit count = 0
4.1: where = temacs`Fnative_comp_unit_set_file + 12 [inlined] TAGGEDP at lisp.h:788:10, address = 0x00000001001556cc, resolved, hit count = 0
it never stopped there.
I think this should be called from loadup.el and set the file names of
the CUs to conses, right?.
But maybe that's because I don't have a debug build here, which makes
things additionally interesting :-(.
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-21 13:11 ` Gerd Möllmann
@ 2022-08-21 13:14 ` Gerd Möllmann
2022-08-21 13:39 ` Gerd Möllmann
0 siblings, 1 reply; 41+ messages in thread
From: Gerd Möllmann @ 2022-08-21 13:14 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: larsi, 57309, akrl
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Does LLDB have the equivalent of "info share" command? If so, do you
>> see window-0d1b8b93-274db3e2.eln in the list of loaded shared
>> libraries after the above?
>
> I did something else also. With a breakpoint on
>
> 4: name = 'Fnative_comp_unit_set_file', locations = 1, resolved = 1, hit count = 0
> 4.1: where = temacs`Fnative_comp_unit_set_file + 12 [inlined]
> TAGGEDP at lisp.h:788:10, address = 0x00000001001556cc, resolved, hit
> count = 0
>
> it never stopped there.
>
> I think this should be called from loadup.el and set the file names of
> the CUs to conses, right?.
>
> But maybe that's because I don't have a debug build here, which makes
> things additionally interesting :-(.
Two more tries, and it doesn't want to stop there.
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-21 13:08 ` Gerd Möllmann
@ 2022-08-21 13:19 ` Eli Zaretskii
0 siblings, 0 replies; 41+ messages in thread
From: Eli Zaretskii @ 2022-08-21 13:19 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: larsi, 57309, akrl
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: larsi@gnus.org, 57309@debbugs.gnu.org, akrl@sdf.org
> Date: Sun, 21 Aug 2022 15:08:27 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > Does LLDB have the equivalent of "info share" command? If so, do you
> > see window-0d1b8b93-274db3e2.eln in the list of loaded shared
> > libraries after the above?
>
> My cheat sheet says that's 'image list' in lldb. And it's there
OK.
The code which errors out and fails the build is relatively new. And
it was supposed to be enabled by the changes in 842c641 and its parent
commit. So maybe the code committed there that was supposed to fixup
all the CUs is not always working?
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-21 13:14 ` Gerd Möllmann
@ 2022-08-21 13:39 ` Gerd Möllmann
2022-08-21 13:45 ` Eli Zaretskii
0 siblings, 1 reply; 41+ messages in thread
From: Gerd Möllmann @ 2022-08-21 13:39 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: larsi, 57309, akrl
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> Two more tries, and it doesn't want to stop there.
And with this in loadup.el
diff --git a/lisp/loadup.el b/lisp/loadup.el
index 634a331436..ded700a671 100644
--- a/lisp/loadup.el
+++ b/lisp/loadup.el
@@ -473,6 +473,7 @@
;; At this point, we're ready to resume undo recording for scratch.
(buffer-enable-undo "*scratch*")
+(message "XXX")
(when (featurep 'native-compile)
;; Fix the compilation unit filename to have it working when
;; installed or if the source directory got moved. This is set to be
@@ -480,7 +481,9 @@
;; (rel-filename-from-install-bin . rel-filename-from-local-bin).
(let ((bin-dest-dir (cadr (member "--bin-dest" command-line-args)))
(eln-dest-dir (cadr (member "--eln-dest" command-line-args))))
+ (message "AAA %s %s" bin-dest-dir eln-dest-dir)
(when (and bin-dest-dir eln-dest-dir)
+ (message "BBB")
(setq eln-dest-dir
(concat eln-dest-dir "native-lisp/" comp-native-version-dir "/"))
(maphash (lambda (_ cu)
@@ -492,6 +495,7 @@
(expand-file-name "preloaded"
eln-dest-dir)
eln-dest-dir)))
+ (message "native-comp-set-file %s" file)
(native-comp-unit-set-file
cu
(cons
I see
Loading leim/leim-list.el (source)...
Loading emacs-lisp/rmc (native compiled elisp)...
Waiting for git...
Waiting for git...
Finding pointers to doc strings...
Finding pointers to doc strings...done
XXX
AAA --eln-dest nil
Pure-hashed: 14904 strings, 1759 vectors, 46342 conses, 1091 bytecodes, 348 others
Dumping under the name emacs.pdmp
I guess we're almost there :-).
The temacs call in my original bug report looked like
rm -f emacs && cp -f temacs emacs
LC_ALL=C ./temacs -batch -l loadup --temacs=pdump \
--bin-dest --eln-dest
Loading loadup.el (source)...
Dump mode: pdump
Note that --bin-dest and --eln-dest have no arguments.
^ permalink raw reply related [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-21 13:39 ` Gerd Möllmann
@ 2022-08-21 13:45 ` Eli Zaretskii
2022-08-21 13:56 ` Gerd Möllmann
0 siblings, 1 reply; 41+ messages in thread
From: Eli Zaretskii @ 2022-08-21 13:45 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: larsi, 57309, akrl
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: larsi@gnus.org, 57309@debbugs.gnu.org, akrl@sdf.org
> Date: Sun, 21 Aug 2022 15:39:25 +0200
>
> rm -f emacs && cp -f temacs emacs
> LC_ALL=C ./temacs -batch -l loadup --temacs=pdump \
> --bin-dest --eln-dest
> Loading loadup.el (source)...
> Dump mode: pdump
>
>
> Note that --bin-dest and --eln-dest have no arguments.
Their values are defined in the top-level Makefile. Why are they
empty in your case?
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-21 13:45 ` Eli Zaretskii
@ 2022-08-21 13:56 ` Gerd Möllmann
2022-08-21 14:02 ` Eli Zaretskii
2022-08-22 8:49 ` Andrea Corallo
0 siblings, 2 replies; 41+ messages in thread
From: Gerd Möllmann @ 2022-08-21 13:56 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: larsi, 57309, akrl
Eli Zaretskii <eliz@gnu.org> writes:
>> Note that --bin-dest and --eln-dest have no arguments.
>
> Their values are defined in the top-level Makefile. Why are they
> empty in your case?
Exactly.
diff --git a/Makefile.in b/Makefile.in
index 78103f897f..7541e8d6b6 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -367,7 +367,7 @@ .PHONY:
# .pdmp containing the new autoloads.
.PHONY: src-depending-on-lisp
src-depending-on-lisp: lisp
- ${MAKE} -C src
+ ${MAKE} -C src BIN_DESTDIR='$(BIN_DESTDIR)' ELN_DESTDIR='$(ELN_DESTDIR)'
# If configure were to just generate emacsver.tex from emacsver.tex.in
# in the normal way, the timestamp of emacsver.tex would always be
Everything falls back on oneself :-).
(BTW, doesn't GNU make have an 'export', or do I misremember that.
Whatever....)
I'll commit this soon.
^ permalink raw reply related [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-21 13:56 ` Gerd Möllmann
@ 2022-08-21 14:02 ` Eli Zaretskii
2022-08-22 8:49 ` Andrea Corallo
1 sibling, 0 replies; 41+ messages in thread
From: Eli Zaretskii @ 2022-08-21 14:02 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: larsi, 57309, akrl
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: larsi@gnus.org, 57309@debbugs.gnu.org, akrl@sdf.org
> Date: Sun, 21 Aug 2022 15:56:16 +0200
>
> diff --git a/Makefile.in b/Makefile.in
> index 78103f897f..7541e8d6b6 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -367,7 +367,7 @@ .PHONY:
> # .pdmp containing the new autoloads.
> .PHONY: src-depending-on-lisp
> src-depending-on-lisp: lisp
> - ${MAKE} -C src
> + ${MAKE} -C src BIN_DESTDIR='$(BIN_DESTDIR)' ELN_DESTDIR='$(ELN_DESTDIR)'
>
> # If configure were to just generate emacsver.tex from emacsver.tex.in
> # in the normal way, the timestamp of emacsver.tex would always be
>
>
> Everything falls back on oneself :-).
Right. As it should.
> (BTW, doesn't GNU make have an 'export', or do I misremember that.
It does.
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-21 10:58 ` Eli Zaretskii
@ 2022-08-22 8:43 ` Andrea Corallo
0 siblings, 0 replies; 41+ messages in thread
From: Andrea Corallo @ 2022-08-22 8:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Gerd Möllmann, larsi, 57309
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: larsi@gnus.org, 57309@debbugs.gnu.org, akrl@sdf.org
>> Date: Sun, 21 Aug 2022 12:45:05 +0200
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > I've removed src/emacs and src/bootstrap-emacs, and said "make". That
>> > succeeded, but most of the preloaded files were loaded as *.elc. Then
>> > I touch'ed every .el file that is preloaded, and said "make" again.
>> > This ELC+ELN-compiled all of them, and then successfully loaded and
>> > dumped them.
>> >
>> > Not sure what that means, but maybe try the same recipe?
>>
>> That it succeeds is kind of what I'm afraid of :-).
>>
>> I think Lars mentioned that a simple second make run made things work
>> for him, and now I'm afraid if I leave the debugger or touch anything, I
>> won't be able to reproduce the error again.
>>
>> BTW, I think I've seen the same bug with the last change to Makefile.in,
>> only with a different error message "...incoherent something...", where
>> Lars mentioned he had seen that sort of error ca. once per month or so.
>>
>> Something is really fishy here.
>
> The *.eln files aren't regenerated unless the corresponding *.el files
> are newer than their *.elc files. This is a basic snafu we are living
> with since the development of Emacs 28, and it still isn't resolved.
> This happens even when Emacs changes in a way that requires a new
> subdirectory under native-lisp/, which is a clear sign that the *.eln
> files need to be regenerated.
>
> So yes, something is definitely "fishy". I suspect that the changes
> Andrea did recently required a bump in the ABI_VERSION value, which
> would then prevent Emacs from trying to load the old *.eln files. But
> maybe I'm missing something. I hope Andrea chimes in soon.
Sorry for being late to the party, I'm back. I don't think (or at least
so far I don't see why) my change should have required a new
ABI_VERSION.
I'm trying to read all this long thread searching for a recipe to
reproduce and understand better what is going on.
Thanks
Andrea
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-21 13:56 ` Gerd Möllmann
2022-08-21 14:02 ` Eli Zaretskii
@ 2022-08-22 8:49 ` Andrea Corallo
2022-08-22 8:56 ` Gerd Möllmann
1 sibling, 1 reply; 41+ messages in thread
From: Andrea Corallo @ 2022-08-22 8:49 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: Eli Zaretskii, larsi, 57309
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Note that --bin-dest and --eln-dest have no arguments.
>>
>> Their values are defined in the top-level Makefile. Why are they
>> empty in your case?
>
> Exactly.
>
> diff --git a/Makefile.in b/Makefile.in
> index 78103f897f..7541e8d6b6 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -367,7 +367,7 @@ .PHONY:
> # .pdmp containing the new autoloads.
> .PHONY: src-depending-on-lisp
> src-depending-on-lisp: lisp
> - ${MAKE} -C src
> + ${MAKE} -C src BIN_DESTDIR='$(BIN_DESTDIR)' ELN_DESTDIR='$(ELN_DESTDIR)'
>
> # If configure were to just generate emacsver.tex from emacsver.tex.in
> # in the normal way, the timestamp of emacsver.tex would always be
>
>
> Everything falls back on oneself :-).
>
> (BTW, doesn't GNU make have an 'export', or do I misremember that.
> Whatever....)
>
> I'll commit this soon.
Sorry for the naive question but I just skimmed the whole thread. Can
we consider this bug understood or there's something that still need
investigation/fix?
Thanks
Andrea
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-22 8:49 ` Andrea Corallo
@ 2022-08-22 8:56 ` Gerd Möllmann
2022-08-22 9:35 ` Andrea Corallo
0 siblings, 1 reply; 41+ messages in thread
From: Gerd Möllmann @ 2022-08-22 8:56 UTC (permalink / raw)
To: Andrea Corallo; +Cc: Eli Zaretskii, larsi, 57309
Andrea Corallo <akrl@sdf.org> writes:
> Can we consider this bug understood or there's something that still
> need investigation/fix?
Thanks Andrea. Yes, it's understood--it was actually a recently
intoduced Makefile issue, combined with the fact that I did not know the
pdumper before, which lead to wild speculations. Should be fixed now
(the speculations :-).
And BTW, thanks for the native compiler!
^ permalink raw reply [flat|nested] 41+ messages in thread
* bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file"
2022-08-22 8:56 ` Gerd Möllmann
@ 2022-08-22 9:35 ` Andrea Corallo
0 siblings, 0 replies; 41+ messages in thread
From: Andrea Corallo @ 2022-08-22 9:35 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: Eli Zaretskii, larsi, 57309
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> Andrea Corallo <akrl@sdf.org> writes:
>
>> Can we consider this bug understood or there's something that still
>> need investigation/fix?
>
> Thanks Andrea. Yes, it's understood--it was actually a recently
> intoduced Makefile issue, combined with the fact that I did not know the
> pdumper before, which lead to wild speculations. Should be fixed now
> (the speculations :-).
Wonderful
> And BTW, thanks for the native compiler!
Thanks!
Andrea
^ permalink raw reply [flat|nested] 41+ messages in thread
end of thread, other threads:[~2022-08-22 9:35 UTC | newest]
Thread overview: 41+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-08-20 12:55 bug#57309: 29.0.50; Build error "trying to dump non fixed-up eln file" Gerd Möllmann
2022-08-20 13:07 ` Lars Ingebrigtsen
2022-08-20 13:12 ` Gerd Möllmann
2022-08-20 13:18 ` Lars Ingebrigtsen
2022-08-20 13:21 ` Gerd Möllmann
2022-08-20 13:26 ` Eli Zaretskii
2022-08-20 13:29 ` Lars Ingebrigtsen
2022-08-20 13:45 ` Eli Zaretskii
2022-08-21 11:55 ` Lars Ingebrigtsen
2022-08-20 13:27 ` Lars Ingebrigtsen
2022-08-20 13:37 ` Gerd Möllmann
2022-08-20 14:32 ` Gerd Möllmann
2022-08-20 15:08 ` Gerd Möllmann
2022-08-21 7:03 ` Gerd Möllmann
2022-08-21 8:50 ` Gerd Möllmann
2022-08-21 10:13 ` Eli Zaretskii
2022-08-21 10:45 ` Gerd Möllmann
2022-08-21 10:58 ` Eli Zaretskii
2022-08-22 8:43 ` Andrea Corallo
2022-08-20 15:25 ` Eli Zaretskii
2022-08-21 6:39 ` Gerd Möllmann
2022-08-21 6:43 ` Eli Zaretskii
2022-08-21 6:47 ` Gerd Möllmann
2022-08-21 7:03 ` Eli Zaretskii
2022-08-21 7:13 ` Gerd Möllmann
2022-08-21 11:57 ` Lars Ingebrigtsen
2022-08-21 12:28 ` Gerd Möllmann
2022-08-21 12:36 ` Eli Zaretskii
2022-08-21 12:46 ` Gerd Möllmann
2022-08-21 12:55 ` Eli Zaretskii
2022-08-21 13:08 ` Gerd Möllmann
2022-08-21 13:19 ` Eli Zaretskii
2022-08-21 13:11 ` Gerd Möllmann
2022-08-21 13:14 ` Gerd Möllmann
2022-08-21 13:39 ` Gerd Möllmann
2022-08-21 13:45 ` Eli Zaretskii
2022-08-21 13:56 ` Gerd Möllmann
2022-08-21 14:02 ` Eli Zaretskii
2022-08-22 8:49 ` Andrea Corallo
2022-08-22 8:56 ` Gerd Möllmann
2022-08-22 9:35 ` Andrea Corallo
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.