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