bug#66022: 30.0.50; kmacro overwriting global keybindings

[Stefan Monnier]

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


        Stefan