[M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110
Jay K
jay.krell at cornell.edu
Fri May 29 17:18:35 CEST 2015
I believe the variable existed for cm3, but not m3cc/cm3cg. Rodney added it for m3cc/cm3cg.
- Jay
> Date: Fri, 29 May 2015 14:04:02 +0200
> From: wagner at elego.de
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; rodney.m.bates at acm.org
> Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110
>
> On Fri, 29 May 2015 11:45:02 +0000
> Jay K <jay.krell at cornell.edu> wrote:
>
> > The workaround is bad, as it affects m3-sys/cm3 also.
> > Rodney, this really should be removed. If you must have something like this, make it a separate variable from cm3. Please.
>
> I don't think Rodney introduced this variable ;-)
>
> Olaf
>
> > - Jay
> >
> >
> >
> > From: jay.krell at cornell.edu
> > To: wagner at elegosoft.com
> > Date: Fri, 29 May 2015 11:22:15 +0000
> > CC: m3devel at elegosoft.com; rodney.m.bates at acm.org
> > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110
> >
> >
> >
> >
> > > if equal($INSTALL_CM3_IN_BIN, "yes")
> >
> >
> > Hm. That is relatively new.
> > Rodney, This is a mistake:
> > https://github.com/modula3/cm3/commit/1994f950bb30c3021fd24c07a555f0f7bace933f
> >
> >
> > I see you commented it heavily, but we had working automation before that this broke.
> > The automation already took into account what you were trying to take into account.
> >
> >
> > I agree having the config search all over, which I did, is not good,
> > as it undermines attempts to ship at just the right time.
> >
> >
> > If you don't want to ship cm3cg, then don't run cm3 -ship for it.
> > cm3cg is not actually running when cm3 -ship is run.
> > The reasons cm3 doesn't ship itself do not apply.
> >
> >
> > I agree it seems tempting to sync this behavior with the behavior of shipping cm3.
> > But I don't think it should be.
> >
> >
> > Yes the files have to be updated together.
> > You do that by shipping cm3cg and somehow otherwise copying cm3.
> > I agree that having this "somehow otherwise copy" is not great.
> > I wonder if we can remove that though.
> >
> >
> > The reason cm3 ship is disabled by default is not so that things are updated together,
> > but because having an executable copy over itself reportedly does not work on some operating systems.
> > It is nothing to do with our need to copy multiple files automatically. It is because it will fail.
> >
> >
> >
> > Now..I must say..Windows is extremely often labeled as one of these systems.
> > Countless people believe this myth. But it isn't true.
> > You can copy over an "in use" .dll or .exe.
> > You merely have to rename it away first. Yes, that is still a bit wierd.
> > And I have to investigate how to eventually delete it.
> > Yes, there is a way to defer the delete..until a reboot..if you are an administrator..
> > but that is clearly an inadequate mechanism. It is quite possible you open with delete_on_close,
> > and close, and then the last close might do it, when the .exe stops running.
> > We should try this out.
> >
> >
> >
> > However, with Windows possibly eliminated as a concern (once ship does the rename, which it doesn't currently),
> > does that leave other systems? AIX I believe is similar..that a direct copy will fail.
> > But will rename work around it there too?
> >
> >
> > Should we let cm3 be able to ship itself, and see what comes of it?
> > Like, maybe every system people really use can do it?
> > When an AIX user speaks up, we can fix it then??
> >
> >
> >
> > Either way, I believe this change to m3cc/src/m3makefile should be undone.
> >
> >
> > In the meantime, everyone can workaround it by setting the environment variable.
> >
> >
> > The other angle, which I've been pushing unsuccessfully is never update in place.
> > That is portable.
> > Start with a new empty directory tree and fill it in by shipping, even cm3.
> > Like make-dist.py does.
> > One wrinkle here is that cm3, if it doesn't already, must favor looking next to itself, and not searching $PATH.
> > So that you ship cm3cg to the new place, and then cm3, and cm3 shipping second finishes the transaction (ok,
> > you'd also copy/ship other files, like configs and m3core/libm3, and then cm3 last).
> >
> >
> >
> > I would really really like that code for an executable to find its full path, on all supported systems.
> > I don't think Posix can do it. Win32 GetModuleFileName(NULL or &__ImageBase) for example.
> > Then strip off the last path element and append stuff, to find things you go with.
> > It is a nice technique.
> > I'm leary of techniques that rely on $PATH search or applying argv[0] to getcwd, as the current directory can change at any time.
> >
> >
> > (and another unsuccessful angle is to move away from all the .sh files; I've been using the .py files for years...well, I was...)
> >
> >
> >
> > - Jay
> >
> >
> >
> > > Date: Thu, 28 May 2015 23:05:54 +0200
> > > From: wagner at elegosoft.com
> > > To: jay.krell at cornell.edu
> > > CC: rodney.m.bates at acm.org; m3devel at elegosoft.com; adacore at marino.st
> > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110
> > >
> > > On Thu, 28 May 2015 20:14:49 +0000
> > > Jay K <jay.krell at cornell.edu> wrote:
> > >
> > > > > 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.
> > > >
> > > > This is very deliberate and should always work, when doing a native upgrade.
> > > > It is true it is not always required.
> > > > When doing a "clean" cross build, it is true that it is backwards.
> > > > It is required when upgrading from an older build.
> > > >
> > > > Native upgrades start at least with a working compiler and its matching runtime.
> > > > Cross builds start with a working host compiler and nothing for the target -- so they do start with m3core.
> > >
> > > I've had a look at the build log, and I think the problem in this case
> > > with upgrade.py might be that it doesn't install the new backend, but
> > > only the new frontend:
> > >
> > > [...]
> > > Not shipping cm3cg.
> > > --- shipping from AMD64_FREEBSD ---
> > >
> > > missing ".M3SHIP" file, build the package first.
> > > dula3/work/bootstrap/bin/cm3 -build -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++
> > > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done
> > >
> > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++
> > > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done
> > >
> > > mkdir -p /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin
> > > cp -Pv /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/cm3/AMD64_FREEBSD/cm3 /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin/cm3
> > > [...]
> > >
> > > In the upgrade.sh script I used install-cm3-compiler.sh, which always
> > > installs both. In m3-sys/m3cc/src/m3makefile I find the following code:
> > >
> > > if equal($INSTALL_CM3_IN_BIN, "yes")
> > > deriveds("", ["cm3cg", "cm3cg.exe"])
> > > write ( "Forced ship of cm3cg." & CR)
> > > BindExport (AppendExeExtension ("cm3cg"))
> > > if DoMipsTfile
> > > BindExport ("mips-tfile")
> > > end
> > > else
> > > write ( "Not shipping cm3cg." & CR)
> > > end
> > >
> > > So perhaps simply setting INSTALL_CM3_IN_BIN=yes in the environment
> > > will fix that problem?
> > >
> > > Olaf
> > > --
> > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com
> > > Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> > > Geschäftsführer: Olaf Wagner | Sitz: Berlin
> > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> >
>
> --
> Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com
> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> Geschäftsführer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150529/b89e6dea/attachment-0002.html>
More information about the M3devel
mailing list