[M3devel] type mismatches?

Tony Hosking hosking at cs.purdue.edu
Tue Apr 22 19:02:47 CEST 2008


This happens whenever you add a new target to the compiler.  You need  
to bootstrap a new compiler with the old libraries (m3core, libm3)  
before trying to build the new libraries containing the new  
Compiler.tmpl.

On Apr 22, 2008, at 8:52 AM, Jay wrote:

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




More information about the M3devel mailing list