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

Jay K jay.krell at cornell.edu
Mon Jun 1 08:54:29 CEST 2015


It only happens if you ship.
Shipping in the wrong order can always break things.
You cannot ship in arbitrary order and incorrect order can cause arbitrary problems.
That doesn't mean we should never ship and always have a separate copy mechanism.
The knowledge of what to ship is meant to be in the m3makefiles. Not also
encoded elsewhere.
 
 
The environment variable check really should be removed.
 
Perhaps perhaps perh
aps shipping order can be enforced?
For things other than m3cc, this seems possible.
Immediate matching dependencies should be present in the destination.
Using the information that is already present in the system as to immediate
and matching, in terms of Modula-3 imports/interfaces.
 
 
m3cc is unique in not fitting in that however.
As well, the dependency between m3cc/cm3 -- what order would you say it is?
Circular but the tie can be broken arbitrarily?
 
 
Introduce a command that can ship multiple packages at once?
I kind of want that anyway, but in this case you'd arrive back at the environment variable,
as long as cm3 has it..though cm3 only needs it for NT and hypothetical other targets
like AIX/OS2/DOS/DJGPP.
 
However -- how about this suggestion -- make the environment variable check for relative native target?
 
Only skip cm3 shipping when we know it doesn't work, I..e NT/Cygwin/Mingwin?
I like this. It is a special case either way, but at least we can demonstrate a cleaner system on most systems..
 
 
 
 - Jay


 
> Date: Sun, 31 May 2015 13:30:46 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com; adacore at marino.st
> Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110
> 
> 
> 
> On 05/31/2015 12:59 PM, John Marino wrote:
> > I removed "INSTALL_CM3_IN_BIN=yes" after reading the thread about it.
> > Should I put it back?  From the last response I'm guessing that wasn't
> > the problem.
> >
> > John
> >
> 
> It apparently wasn't the only problem, but it definitely was a problem.
> Don't put it back.  I causes the new cm3cg executable to be copied
> to your bin directory immediately after it has been built.  It is
> incompatible with the old cm3 executable, and the next attempted
> build (m3core, as I remember) runs the old cm3, then the new cm3cg,
> which correctly recognizes that its input is in an old version format
> and refuses, giving the error message.
> 
> >
> > On 5/31/2015 19:09, Jay K wrote:
> >> Oh probably the problem is using the backend premature actually.
> >> Darn, I can't help right now.
> >>
> >>   - Jay
> >>
> >>
> >>
> >> ------------------------------------------------------------------------
> >> From: jay.krell at cornell.edu
> >> To: adacore at marino.st; m3devel at elegosoft.com
> >> Date: Sun, 31 May 2015 16:45:42 +0000
> >> Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp
> >> (0x100), expected 0x110
> >>
> >> Hm. Strange. I need to read more closely. I see it skipping shipping,
> >> but my read was it didn't try that.
> >> So.. with INSTALL_CM3_IN_BIN=yes?
> >> I need to try this all, and "fix" it to set that. The whole thing in
> >> m3cc/src/m3makefile is relatively
> >> new vs. when I was actively using all this. :(
> >>
> >>   - Jay
> >>
> >>
> >>> Date: Sun, 31 May 2015 16:57:02 +0200
> >>> From: adacore at marino.st
> >>> To: jay.krell at cornell.edu; m3devel at elegosoft.com
> >>> Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp
> >> (0x100), expected 0x110
> >>>
> >>> On 5/31/2015 11:53, Jay K wrote:
> >>>> John, have you tried make-dist.py?
> >>>> i.e.
> >> https://github.com/modula3/cm3/blob/master/scripts/python/make-dist.py
> >>>>
> >>>> While it might not be exactly what you need, it should demonstrate the
> >>>> elements.
> >>>>
> >>>> I will try to try this all soon, really, I hope so.
> >>>>
> >>>> It starts with a working compiler, does no in-place updates, build into
> >>>> a unique directory in /tmp, and gives you .tar.gz or such at the end.
> >>>> It does "min" and "all".
> >>>>
> >>>> If you set the STAGE environment variable, it uses that instead of /tmp.
> >>>> It should probably be called M3_STATE or M3_MAKEDIST_STAGE.
> >>>>
> >>>> - Jay
> >>>>
> >>>
> >>> Hi Jay,
> >>> I'm getting the same error as always using make-dist script:
> >>> http://leaf.dragonflybsd.org/~marino/m3d.log
> >>>
> >>> 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/d043b3e8/attachment-0002.html>


More information about the M3devel mailing list