[M3devel] type mismatches?

[Jay]

4797  NEXT    Fatal Error: bad version stamps: SocketPosix.m3
4798          
4799          version stamp mismatch: Compiler.Platform
4800             => SocketPosix.m3
4801             => Compiler.i3  
4802          version stamp mismatch: Compiler.ThisPlatform
4803             => SocketPosix.m3
4804             => Compiler.i3  

This is now in the Tinderbox, on some machines, e.g. FreeBSD4.
I have two source trees on same machine sharing same install root, one sees it, one does not.
  Even though I start the install root out by extracting the same initial snapshot, I think.
  I think they are the same except for path but that needs scrutiny.

I am making SOME attempt to isolate it, but I'm not looking forward to it..
One expensive potshot is wait for a full hours-long gcc build with no switches.
In case it is a cm3cg problem, emanating from the compiler used to build cm3cg.
(I just did another build of cm3cg, took 11 minutes..)

That is:
 There is a problem here. It's not just me.  I MIGHT find it.
 If anyone can save me the trouble, please do. :)

Other potshots include more conservative codegen like -fno-reorder-blocks -mno-double-align -O0, some/all of which are already in use. I was going to commit blindly such conservatism for FreeBSD4, however my local repro is persisting despite this.

It could still be some simple bootstrapping issue. I don't know.

SocketPosix is only using Compiler for some dormant platforms. The code is probably dead.
But hey, extra dead code finds extra live bugs. :)

Question:
  Am I correct that, in the absence of cm3/cm3cg/underlying bugs, the following should never occur:
  cd .../m3core 
  rm -rf 
  cm3
  cm3 -ship 
  cd ../libm3 
  rm -rf 
  cm3
  => version stamp mismatch 

? That is -- if this happens, it can't be any bootstrapping problem? These checks are libm3 vs. m3core, right? What the compiler itself is?

 - Jay