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

Fri May 29 13:42:32 CEST 2015

 > One wrinkle here is that cm3, if it doesn't already, must favor looking next to itself, and not searching $PATH.

dladdr appears to be the answer.
It appears to be supported on MacOSX 10.4. OpenBSD, NetBSD, FreeBSD, Solaris, AIX, HP-UX, Irix, OpenVMS, Tru64.
At least later versions of all of them. Non-authoritative web searches indicate so...
And GetModuleFileName on Windows.

Any objections to using it in cm3? (and GetModuleFileName on Windows)?

This way, cm3 can easily and reliably look next to itself for config files and the pkg directory and cm3cg.
I can double double check, but I doubt what it does today is totally reliable.

Thanks,
 - 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150529/b5c7c8a0/attachment-0002.html>