Sorry, missed copying a line from the terminal
/ > ls -l
/Applications/Emacs.app/Contents/Resources/lisp/loaddefs.el*
-rw-r--r-- 1 gerd admin 377687 Sep 17 16:36
/Applications/Emacs.app/Contents/Resources/lisp/loaddefs.el.gz
-rw-r--r-- 1 gerd admin 1467107 Sep 17 16:38
/Applications/Emacs.app/Contents/Resources/lisp/loaddefs.elc
gerd@Pro 2023-09-18 18:32 ~/ >
I believe the `lread.c` code which calls `Fload` should be looking at
the `loaddefs.elc` file here, so removing the `.el.gz` should make no
difference.
Now why does it feel the need to reload this file? The way the code
works is that it receives a (FILE . POS) pair where FILE should
presumably point to the `loaddefs.elc`.
When it opens that `.elc` file, POS should point to the beginning of
the desired docstring with nearby info indicating the length of that
docstring.
If the file was changed in the mean time, POS may end up pointing
elsewhere. `lread.c` performs a sanity check to make sure POS
points to something that does indeed look like a docstring and
apparently in your case that sanity check fails.
My crystal ball suggests maybe you're witnessing a bug in the build
process where we end up *re*compiling `loaddefs.elc` a second time
(maybe because we regenerate/refresh `loaddefs.el` by error) after
Emacs was dumped, maybe during the "install" step that builds the
`Emacs.app`.
Normally, the way things are supposed to work is:
- build temacs. - dump bootstrap-emacs using some old
`loaddefs.el(c)` of `ldefs-boot.el`. - compile the preloaded files
and build the true `loaddefs.el`. - dump the final `emacs`
executable. - keep compiling the rest.
But if "keep compiling the rest" ends up touching a dependency of
`loaddefs.el` subsequent steps like `install` could decide to make
poor decisions :-(
IOW rebuild, keeping a log and check what was done in which order.