[M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110
Olaf Wagner
wagner at elego.de
Fri May 29 14:04:02 CEST 2015
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 --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150529/78d512b5/attachment-0002.sig>
More information about the M3devel
mailing list