<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><div>The build order in upgrade.py is correct.</div><div><br></div><div><br></div><div>Since it is deliberately starting with whatever cm3 the user already has,</div><div>it must also start deliberately with whatever m3core and libm3 the user already has.</div><div>They go together.</div><div><br></div><div><br></div><div>It builds a cm3 that uses the old m3core/libm3 (statically linked),</div><div>and then rebuilds everything with itself, starting from m3core.</div><div>"everything" being only up to cm3/mklib, not the gui stuff, for example.</div><div><br></div><div><br></div><div><br></div><div>Really in the past I've used this stuff a lot and I use the unedited checked in copy.</div><div>There could be a problem building from the latest release, and that we should fix.</div><div>The problem will likely be in m3front/m3back/m3link/m3quake, etc. The scripts should already be ok.</div><div><br></div><div><br></div><div><div>The in-place nature of upgrade.py is perhaps not ideal. Esp. when it doesn't work.</div><div>make-dist.py may be preferable.</div></div><div><br></div><div><br></div><div> - Jay<br><br><br><br></div><div>> Date: Thu, 28 May 2015 17:56:20 +0200<br>> From: adacore@marino.st<br>> To: rodney.m.bates@acm.org; m3devel@elegosoft.com<br>> Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110<br>> <br>> On 5/28/2015 17:01, Rodney M. Bates wrote:<br>> > I don't know why that happened. I don't have experience with the<br>> > Python scripts.<br>> > <br>> > Jay?<br>> > <br>> > Also, this script built the compiler before the support libraries<br>> > m3core and libm3. I think there may have been one bootstrap scenario<br>> > where this was the way it needed to be done, but usually it is the<br>> > other way around--these two libraries first.<br>> > <br>> >> Am I doing some kind of obvious mistake?<br>> >> <br>> > No, it's a bootstrap barrier. These pop up somewhat regularly. We<br>> > all usually just build from the most recent development build, which<br>> > works for getting new things tried out initially. But we need to<br>> > make a habit of regularly rebuilding from the previous release to<br>> > flush these out.<br>> <br>> Olaf said, IIUC, that the current code can't be built by the last<br>> release compiler. Putting aside that I believe that should be a hard<br>> requirement for the project, it sounds like maybe the last release can<br>> build it if the build order is fixed (e.g. a better upgrade.py script)?<br>> It's not clear to me what the real situation is.<br>> <br>> <br>> > You might try scripts/do-cm3-front.sh realclean <br>> > scripts/do-cm3-front.sh buildship<br>> > <br>> > (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg<br>> > at this point. The step below does it somewhat redundantly, but only<br>> > one level, unless the version number changes.)<br>> > <br>> > scripts/install-cm3-compiler.sh upgrade.<br>> > From here, you are using the new compiler.<br>> > scripts/do-cm3-<whatever-else-you-want>.sh buildship<br>> > <br>> > That this works, starting with the previous release compiler, is my <br>> > criterion for having removed bootstrap barriers.<br>> <br>> My work takes place within a Makefile and moving things in /usr/local<br>> (for example) is actually illegal. Now I could do all this manually for<br>> the purpose of building a new bootstrap, but as I mentioned in a<br>> previous post, it might be more effective to emulate what you guy have<br>> done: essentially build a series of bootstraps at strategic hashes until<br>> I've acquired a compiler that can build this (and then use that product<br>> as bootstrap for FreeBSD ports).<br>> <br>> If I did that approach, I could use a hint on the hashes to try...<br>> <br>> John<br></div> </div></body>
</html>