<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
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.<br><br>Oh, I think I see now.<br>m3front/src/builtInfo/InfoModule.m3<br><br>This will happen also if you only change one side.<br>Could be I had that edit on my machine.<br><br>Still not sure about the Tinderbox but I'll wait and see.<br><br>Thanks,<br> - Jay<br><br>> CC: m3devel@elegosoft.com<br>> From: hosking@cs.purdue.edu<br>> To: jayk123@hotmail.com<br>> Subject: Re: [M3devel] type mismatches?<br>> Date: Tue, 22 Apr 2008 13:02:47 -0400<br>> <br>> This happens whenever you add a new target to the compiler.  You need  <br>> to bootstrap a new compiler with the old libraries (m3core, libm3)  <br>> before trying to build the new libraries containing the new  <br>> Compiler.tmpl.<br>> <br>> On Apr 22, 2008, at 8:52 AM, Jay wrote:<br>> <br>> ><br>> > 4797  NEXT    Fatal Error: bad version stamps: SocketPosix.m3<br>> > 4798<br>> > 4799          version stamp mismatch: Compiler.Platform<br>> > 4800             => SocketPosix.m3<br>> > 4801             => Compiler.i3<br>> > 4802          version stamp mismatch: Compiler.ThisPlatform<br>> > 4803             => SocketPosix.m3<br>> > 4804             => Compiler.i3<br>> ><br>> > This is now in the Tinderbox, on some machines, e.g. FreeBSD4.<br>> > I have two source trees on same machine sharing same install root,  <br>> > one sees it, one does not.<br>> >  Even though I start the install root out by extracting the same  <br>> > initial snapshot, I think.<br>> >  I think they are the same except for path but that needs scrutiny.<br>> ><br>> > I am making SOME attempt to isolate it, but I'm not looking forward  <br>> > to it..<br>> > One expensive potshot is wait for a full hours-long gcc build with  <br>> > no switches.<br>> > In case it is a cm3cg problem, emanating from the compiler used to  <br>> > build cm3cg.<br>> > (I just did another build of cm3cg, took 11 minutes..)<br>> ><br>> > That is:<br>> > There is a problem here. It's not just me.  I MIGHT find it.<br>> > If anyone can save me the trouble, please do. :)<br>> ><br>> > Other potshots include more conservative codegen like -fno-reorder- <br>> > blocks -mno-double-align -O0, some/all of which are already in use.  <br>> > I was going to commit blindly such conservatism for FreeBSD4,  <br>> > however my local repro is persisting despite this.<br>> ><br>> > It could still be some simple bootstrapping issue. I don't know.<br>> ><br>> > SocketPosix is only using Compiler for some dormant platforms. The  <br>> > code is probably dead.<br>> > But hey, extra dead code finds extra live bugs. :)<br>> ><br>> > Question:<br>> >  Am I correct that, in the absence of cm3/cm3cg/underlying bugs, the  <br>> > following should never occur:<br>> >  cd .../m3core<br>> >  rm -rf<br>> >  cm3<br>> >  cm3 -ship<br>> >  cd ../libm3<br>> >  rm -rf<br>> >  cm3<br>> >  => version stamp mismatch<br>> ><br>> > ? That is -- if this happens, it can't be any bootstrapping problem?  <br>> > These checks are libm3 vs. m3core, right? What the compiler itself is?<br>> ><br>> > - Jay<br>> <br></body>
</html>