[M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110

[Jay K]

The build order in upgrade.py is correct.

Since it is deliberately starting with whatever cm3 the user already has,it must also start deliberately with whatever m3core and libm3 the user already has.They go together.

It builds a cm3 that uses the old m3core/libm3 (statically linked),and then rebuilds everything with itself, starting from m3core."everything" being only up to cm3/mklib, not the gui stuff, for example.


Really in the past I've used this stuff a lot and I use the unedited checked in copy.There could be a problem building from the latest release, and that we should fix.The problem will likely be in m3front/m3back/m3link/m3quake, etc. The scripts should already be ok.

The in-place nature of upgrade.py is perhaps not ideal. Esp. when it doesn't work.make-dist.py may be preferable.

 - Jay



> Date: Thu, 28 May 2015 17:56:20 +0200
> From: adacore at marino.st
> To: rodney.m.bates at acm.org; m3devel at elegosoft.com
> Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110
> 
> On 5/28/2015 17:01, Rodney M. Bates wrote:
> > I don't know why that happened.  I don't have experience with the
> > Python scripts.
> > 
> > Jay?
> > 
> > Also, this script built the compiler before the support libraries
> > m3core and libm3.  I think there may have been one bootstrap scenario
> > where this was the way it needed to be done, but usually it is the
> > other way around--these two libraries first.
> > 
> >> Am I doing some kind of obvious mistake?
> >> 
> > No, it's a bootstrap barrier.  These pop up somewhat regularly.  We
> > all usually just build from the most recent development build, which
> > works for getting new things tried out initially.  But we need to
> > make a habit of regularly rebuilding from the previous release to
> > flush these out.
> 
> Olaf said, IIUC, that the current code can't be built by the last
> release compiler.  Putting aside that I believe that should be a hard
> requirement for the project, it sounds like maybe the last release can
> build it if the build order is fixed (e.g. a better upgrade.py script)?
>  It's not clear to me what the real situation is.
> 
> 
> > You might try scripts/do-cm3-front.sh realclean 
> > scripts/do-cm3-front.sh buildship
> > 
> > (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg
> > at this point. The step below does it somewhat redundantly, but only
> > one level, unless the version number changes.)
> > 
> > scripts/install-cm3-compiler.sh upgrade.
> > From here, you are using the new compiler.
> > scripts/do-cm3-<whatever-else-you-want>.sh buildship
> > 
> > That this works, starting with the previous release compiler, is my 
> > criterion for having removed bootstrap barriers.
> 
> My work takes place within a Makefile and moving things in /usr/local
> (for example) is actually illegal.  Now I could do all this manually for
> the purpose of building a new bootstrap, but as I mentioned in a
> previous post, it might be more effective to emulate what you guy have
> done: essentially build a series of bootstraps at strategic hashes until
> I've acquired a compiler that can build this (and then use that product
> as bootstrap for FreeBSD ports).
> 
> If I did that approach, I could use a hint on the hashes to try...
> 
> John
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150528/0bdf6626/attachment-0002.html>