Loading tramp for dump goes into infinite regress

[Lynn Winebarger <owinebar@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1892 bytes --]

And I don't even know where to start describing the issue.
It starts with having "(require 'tramp-loaddefs)" in tramp.el.  That's a
nonstarter for dumping, so I extracted all the variable/constant defs from
tramp-loaddefs and put them in a separate file "tramp-consts.el", removed
them from tramp-loaddefs, and then require the tramp-consts in tramp.el at
the same place.  I also added explicit declare-function for all the
functions the compiler complaints about being missing.
Then, at the end of the file, after the provide statement, I've tried
various ways of having the effect of the "require tramp-loaddefs" call
before the tramp init hook functions are run, since those are set in
tramp-loaddefs.  I tried just putting the require tramp-loaddefs there,
loading tramp-loaddefs, explicitly loading the individual files
(conditioned on dump-mode being nil), but all for naught.

If I wrap the "provide 'tramp" call with eval-and-compile, the dump will
successfully load it, but batch compiling it will fail on the "provide"
saying that tramp-methods variable is void.  This happens even if I've
removed the expressions following the provide.  And when I use "message"
calls to track where it's failing, the procedure definitely fails on the
provide.  It seems to be triggering some load procedure that's pulling in
the expressions created by tramp--with-startup, but I can't find the
expression responsible!
If I don't put the provide in an eval-and-compile, then the file compiled,
but when I run the dumping process (via make), it gets to "loading
net/tramp.elc" and just stops until all memory is consumed and the kernel
kills it.  Or I interrupt it.  We're talking tens of GBs of RAM being
consumed here.  If that were "real" and not some runaway meta-recursive
load cycle I wouldn't want the dumped emacs anyway.

Any advice on how I figure out what is going on here?

Thanks,
Lynn

[-- Attachment #2: Type: text/html, Size: 2306 bytes --]