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

[Jay K]

> OK, the fix I mentioned is in the 5.8 release branch on github, but it is
> not in the above bootstrap.  In file bootstrap/etc/modula3/cm3cfg.common,
> line 274 needs to change from:

> 274:            foreach root in [ m3cc, bin ]

 > to:

 > 274:            foreach root in [ bin ]

> Before building the Modula-3 head.
 
 
Yes, agreed.
I still want the environment variable check removed, but this is another problem,
that I caused, and I did fix long ago, but is causing grief still, sorry about that.
 
 
Here, I fixed it in 2010:

 https://github.com/modula3/cm3/commit/65551f30a6c3ed2cd9740394a9082ffab1b07faa 

 INSTALL_ROOT/bin/cm3cg for native builds 
 ROOT/m3-sys/m3cc/HOST/TARGET/cm3cg for cross builds 
 "Later" (never?) we can think about "installed" cross builds. 

 In particular, when I make m3cg interface changes, I get 
 burned by reaching in for ROOT/m3-sys/m3cc/x/cm3cg. 

 
The code is a lot smaller now and more correct.
Sorry about that. I was being ambitious in trying
to make things work, and it turned out to be quite incorrect
once things are better understood.

 
 
  - Jay



 
> Date: Sun, 31 May 2015 15:51:10 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110
> 
> 
> 
> On 05/31/2015 02:26 PM, John Marino wrote:
> > On 5/31/2015 21:13, Rodney M. Bates wrote:
> >> The error message you keep getting pretty certainly means it is running a
> >> new cm3cg with an old cm3.  And it consistently happens immediately after
> >> cm3cg is rebuilt.
> >>
> >> The build of cm3cg (package m3cc) appears to be the first use of cm3 in all
> >> your failed builds, and I don't think that package would ever run cm3cg, as
> >> there is no Modula-3 code in it.  Which means there is no proof that the
> >> version of cm3cg that would have been used before it was rebuilt is the old
> >> one.  (Could it be a new one left over from a previous incomplete build?)
> >
> > That's not possible.  The bootstrap is packaged in a compressed tarball
> > and extracted for the sole purpose of building M3.  It would have not
> > leftovers in it.
> >
> > It comes with cm3, cm3cg, m3bundle, and mklib in the bin directory.
> >
> > the contents of the bootstrap M3 cm3.cfg are:
> > INSTALL_ROOT = path() & "/.."
> > include (path() & "/../etc/modula3/AMD64_FREEBSD")
> >
> >
> >> One experiment that would prove this would be, in the state your are
> >> starting from before trying a full build, try any means of running
> >> cm3 on a package that contains Modula-3 code, to see if it avoids the
> >> recurring problem.
> >
> > I think this is N/A.  The bootstrap compiler is extracted to a directory
> > that is not on the path (and only exists right before trying to build
> > modula3 port)
> >
> >
> >> But I have another theory.  I don't know what this ports bootstrap
> >> is, but there was a time when things where set up so that cm3, instead
> >> of looking in just the same directory as its own executable was found,
> >> was looking several alternative places for an executable cm3cg. This
> >
> > It's 5.8.6 and the cm3.cfg is listed above.  You can download it
> > yourself here:
> > http://downloads.dragonlace.net/m3/m3-bootstrap.AMD64.FREEBSD.92.tar.bz2
> >
> 
> OK, the fix I mentioned is in the 5.8 release branch on github, but it is
> not in the above bootstrap.  In file bootstrap/etc/modula3/cm3cfg.common,
> line 274 needs to change from:
> 
> 274:            foreach root in [ m3cc, bin ]
> 
> to:
> 
> 274:            foreach root in [ bin ]
> 
> Before building the Modula-3 head.
> 
> >
> >> caused the same problem to occur in a different way.  Even when the
> >> newly rebuilt cm3cg executable was not copied to the bin directory
> >> right away, its mere existence where it was built was causing it to
> >> be found the next time cm3 started up, leading to the same failure.
> >>
> >> I don't remember how this was fixed, but either Jay or I did something
> >> about it.  Perhaps the ports bootstrap was made during a time when this
> >> behavior was happening.
> >
> > Probably not as I am 99% sure the bootstrap was built from the release
> > source.
> >
> > Thanks,
> > John
> >
> >
> >
> >
> 
> -- 
> Rodney Bates
> rodney.m.bates at acm.org
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150601/86a5ab21/attachment-0002.html>