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

Rodney M. Bates rodney_bates at lcwb.coop
Mon Jun 1 19:48:34 CEST 2015 


On 06/01/2015 01:40 AM, Jay K wrote:
> Yes, exactly, that's what I was trying to say, in my later/last mail.
>
>
> Yes the compability is definitely two-way.
> There is a one to one mapping back and forth.
> cm3 goes with cm3cg; cm3cg goes with cm3.
> Neither is compatible with older nor necessarily newer versions.
>
>
> They would be statically linked together if not for the GPL.
>
>
> When I first placed m3cc in pkginfo.txt years ago, I was only thinking
> of build order and, like, "override".
>
>
> m3cc imports nothing and nothing imports m3cc.
> In the Modula-3 module/library/interface sense.
>
>
> It can be built when you have nothing.
> So I figured put it nearly first.
>
>
> Only now today did I consider the shipping order.
> It should be shipped adjacent to cm3, either right before or right after.
>
>
> If you split build and ship, then it can still be built early,
> or at almost any time.
>

Yes, this is the way I want to do building.  First build everything you want to
without putting any of it into use as build tools.  Then put it all into use.

One annoyance we currently have is that the do-cm3.*.sh scripts have, perhaps
we should call them subcommands, like realclean, build, ship, buildship, etc.
But the cm3 command treats their counterparts as command line options,
-realclean, -build, -ship, -buildship, etc.  I would like to consistify
this.  Removing the hyphen from cm3 would create ambiguities with file names,
so it would mean adding the hyphen to the scripts.

Much more serious is that similarly-named options do not have the same meaning
in the scripts and in cm3.  cm3 -build followed by cm3 -ship works as I expect,
but do-cm3-*.sh build causes me nothing but trouble, and I learned long ago to
avoid it.  Instead, I always use do-cm3-*.sh buildship.  This ships almost everything
as it is built, but usually only cm3 and cm3cg executables matter, and today, they are
specifically excepted from shipping, if you do not set INSTALL_CM3_IN_BIN="yes".

I am writing from memory, but I think the problem with do-cm3-*.sh build is that
build also uses overrides, which I barely understand, except that they, at best
make things unshippable, and I think there was some other problem too.  If we
made the override thing a separate option to the scripts, so just build would
neither ship nor override, I think that would satisfy my need, at least for the
time being.  And it would be consistent.

Actually, I think we do want to use just-rebuilt packages when linking to them.
Only executables and things they link in (possibly dynamically) need to be
left alone until a later ship step.  This usually only means cm3, cm3cg,
and, if dynamically linked in, m3core.  But there are others to think about,
e.g., m3bundle, stubgen, netobjgen.

>
> But we have one ordering for build and ship, so let the shipping order decide.
>
>
> I still don't like INSTALL_CM3_IN_BIN and I'd still like to remove it.

I have no objection to addressing the copy-over-an-executing-executable problem
in a different way, and no objection to getting rid of the environment variable.
But I do want it, for now at least, to be possible to get it to not ship either
cm3 or cm3cg, even with the buildship option.  If it just unconditionally doesn't
ship them, that is fine.  Before I added the variable check for the cm3cg package,
it was unconditionally shipping it.

> I still think it broke upgrade.py.
> I can workaround. But I'd like to remove the environment variable check.
>
>
> There are many order dependencies in build and ship. This is just one.
>
>
>   - Jay
>
>
>
>
>  > Date: Sun, 31 May 2015 22:28:13 -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
>  >
>  > I am quite sure that the cm3/cm3cg incompatibility is two-way, i.e.,
>  > both must be new or both old. So, I would expect INSTALL_CM3_IN_BIN=yes
>  > to fail regardless of the order of building the two.
>  >
>  > OTOH, if cm3 were built and shipped, then m3cc came immediately after,
>  > it should work, because m3cc contains no Modula-3 code, and the new
>  > cm3 would not, when building it, run cm3cg. After that, there would
>  > be a consistent set. for further compiles. But any package containing
>  > M3 code built between cm3 and m3cc would fail.
>  >
>  > On 05/31/2015 05:15 PM, Jay wrote:
>  > > I think now it might not be the problem. Could be m3cc needs to be later in pkginfo.txt. I have to try later.
>  > >
>  > > - Jay
>  > >
>  > > On May 31, 2015, at 10:59 AM, John Marino <adacore at marino.st> 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
>  > >>
>  > >>
>  > >> 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

-- 
Rodney Bates
rodney.m.bates at acm.org

More information about the M3devel mailing list