bug#48342: native-comp emacs gets into an infinite loop at startup if no .el files are available

[Dima Kogan]

Hi. I maintain Debian packages of bleeding-edge emacs builds:

  http://emacs.secretsauce.net/

Recently I enabled the native-comp flags for these packages. The results
mostly work, but a user sent me a bug report whose cause I just tracked
down. Some of this is probably my fault, as the packager, but there's an
emacs bug here too.

To tickle the bug the user needs to install the emacs-snapshot package,
but NOT the emacs-snapshot-el package. This results in the .elc files
being shipped, but NOT the .el files. This is a valid way to do it
without the native-comp patches, and the Debian emacs packages have
allowed this since forever.

If you install emacs like this, this happens:

  $ emacs-snapshot -Q -batch -f batch-native-compile empty.el

  Fatal error 11: Segmentation fault

The C backtrace is 6033 frames long, which can't be good. xbacktrace
says this:

  (gdb) xbacktrace
  "display-warning" (0xffebcfd8)
  "display-warning" (0xffebd5d8)
  .... lots more "display-warning"
  "locate-file" (0xffffe498)
  "command-line" (0xffffe5a0)
  "normal-top-level" (0xffffe640)

And the warning itself is:

  "Cannot look-up eln file as no source file was found for 
/usr/share/emacs/28.0.50/lisp/emacs-lisp/warnings.elc"

So something somewhere wanted to throw a warning, and this warning tried
to find its own sources, couldn't do it, and threw another warning. And
so on.

So first off, it'd be great if emacs could handle this without such a
recursive failure mode. It took me a long time to figure out what's
happening, and a plain-text error message on the console would have been
nice.

And second: how should this be packaged? Is shipping the .el files a
hard requirement now?

Thanks!