[M3devel] type mismatches?

[Jay]

Tony, I thought I understood, I thought the automation handled this, both that I run and that the Tinderbox runs, such that one would never see this. I'll poke around a bit more.

Oh, I think I see now.
m3front/src/builtInfo/InfoModule.m3

This will happen also if you only change one side.
Could be I had that edit on my machine.

Still not sure about the Tinderbox but I'll wait and see.

Thanks,
 - Jay

> CC: m3devel at elegosoft.com
> From: hosking at cs.purdue.edu
> To: jayk123 at hotmail.com
> Subject: Re: [M3devel] type mismatches?
> Date: Tue, 22 Apr 2008 13:02:47 -0400
> 
> 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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080422/9095e8c7/attachment-0002.html>