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

Thu May 28 22:14:49 CEST 2015

 > 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.

 The idea that people don't get right away is that the compiler 
 and runtime are very coupled. A compiler targets a particular runtime.
 Its output requires a certain runtime.

 Look at RT0.i3 in particular.
 We haven't changed that in over 10 years, but Critical Mass did.
 For example.

 Or if you change the size of WIDECHAR. 

 The compiler outputs data that the garbage collector uses. 
 The compiler outputs function calls that are to functions in m3core.

 The coupling to libm3 is less clear to me, but the coupling to m3core is significant.

 m3core is kind of the lowest level runtime that compiler pretty much unavoidably requires to be with its output. 

 Perhaps if you write code w/o any traced types and without try/finally or raise, you can avoid m3core. But there
 is still module initialization and running "main". So m3core is unavoidable.

 In the Unix world, consider like crtstart.o.
 In the Windows world, consider that main is called from mainCRTStartup and this is like wherever that is.
 (Or DllMain is called from DllMainCRTSTartup, WinMain is called from WinMainCRTStartup, etc.
 There is an analog between DllMain and the entry points of each module other than Main.)

 libm3 is more a convenience library that you can maybe possibly do without.
 Consider this, like, not the startup code, but stdio, stdlib, STL, etc.

 Another dependency people don't understand is between the frontend and the backend. The gcc backend in particular.
 When you change the "M3CG", the persisted IR, these two have to be updated together.

 Again, these things don't change much, so we get away without worrying about and without automating it and without people understanding it.

 We changed this, for example, when the atomics were added.
 I think I made changes too.

 I believe I automated this, but then wimped out and commented out one line. I'll report back later on this. 
 I didn't want to diverge from the shell scripts, perhaps.

 I'll try to find some time here.
 I agree an upgrade from 5.8.6 to current is desirable.
 I go back and forth on this. I have likely broken it, and fixed it.
 For example, the mklib dependency on the Win32 headers. That should be ok now.
 For another potential example, the frontend can't use LONGINT until a release has it. But I think we have that now.

  We do not support going arbitrarily back, but the previous release is a good target.
  I have at times gone further back and fixed things up. 

  You can also bootstrap via the cross mechanism even if you aren't crossing, but I suppose that is too difficult. 
 Here:
 https://github.com/modula3/cm3/blob/master/scripts/python/upgrade.py 
51 # 
52 # ... and continue with the backend, if needed 
53 # 
54 

55 a = Root + "/m3-sys/m3cggen/" + Target + "/m3cggen > " + Root + "/m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h" 
56 print(a) 
57 # os.system(a) 
58 FilterPackages([ "m3cc" ]) and DoPackage(argv_BuildShip, [ "m3cc" ]) 

uncomment out line 57.
That is where I wimped out. That line should be there.
Hopefully it is still correct.It is a little gross in that it outputs into the source tree.This really shouldn't be needed if you build correctly from a consistent checkout. It is only for when you have local edits.Even bootstrap/upgrade should not require it. The output should just match what is already there.

And another thing: When I wrote upgrade.py, I thought I was mimicking upgrade.sh, and I mostly was.
One thing I missed though was that upgrade.sh does actually build the entire system, whereas upgrade.py
only builds the compiler.

 So consider this, somewhat overkill instead: 
 cd scripts
 ./upgrade.py && ./do-cm3-all.py realclean skipgcc && ./do-cm3-all buildship skipgcc  

 Also note that in-place updates are done while it goes. Certain errors force a need to go backwards.
 So you should maintain a backup of the minimum -- cm3, cm3.cfg, config directory, m3core, libm3, cm3cg.
 Or be able to restore from a release.

 That list is important, so I'll repeat: cm3, cm3.cfg, config directory in newer releases (cm3.cfg delegages to it), m3core, libm3, cm3cg (optional). 

 To put this another way: consider the compiler itself to be a very portable and minimalist Modula-3 program.
 It has few dependencies and does most things itself.

 Consider the C program that just uses very little of the standard library but does use printf("main").

 What do you need to build such things? You don't need, you know, a marshaling library, a windowing library etc.,
 but you need a working compiler, frontend, backend, assembler, linker, and a minimal library

 That is what is required to a native upgrade.

 - Jay

> Date: Thu, 28 May 2015 10:01:21 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110
> 
> 
> On 05/28/2015 06:49 AM, John Marino wrote:
> > I got stuck again trying to build the latest on FreeBSD.
> >
> > 1. tar extracted to working directory along with a bootstrap compiler
> > 2. CM3 and CM3_INSTALL defined in environment
> > 3. executed scripts/python/upgrade.py
> >
> > result:
> > http://leaf.dragonflybsd.org/~marino/m3.log
> >
> > I could guess that something is picking up a bootstrap component instead
> > of a newly built one.
> 
> Yes.
> 
>    >> m3cgc1: fatal error:  *** bad M3CG version stamp (0x100), expected 0x110
> 
> means it is trying to compile using a new cm3cg backend and an old cm3 front end.
> I just added this error message after Olaf had this problem.  (Otherwise it would
> have failed anyway, but with a less informative message.)
> 
> > I guess it's trying to build the c backend?
> >
> 
> It finished the C backend and was trying to build m3core, using the inconsistent
> compiler.  Usually, neither cm3 nor cm3cg is copied to the bin directory,
> even when doing a ship, in order to avoid this, which is an exception.  For all
> other executables, ship copies them to the bin directory.  The shell script
> scripts/install-cm3-compiler.sh is then run manually, after both cm3 and cm3cg
> are compiled, to copy them to bin atomically (sort of).
> 
> I don't know why that happened.  I don't have experience with the Python scripts.
> 
> Jay?
> 
> 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.
> 
> 
> > Am I doing some kind of obvious mistake?
> >
> 
> No, it's a bootstrap barrier.  These pop up somewhat regularly.  We all usually
> just build from the most recent development build, which works for getting new
> things tried out initially.  But we need to make a habit of regularly rebuilding
> from the previous release to flush these out.
> 
> You might try scripts/do-cm3-front.sh realclean
>                scripts/do-cm3-front.sh buildship
> 
> (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg at this point.
>   The step below does it somewhat redundantly, but only one level, unless the
>   version number changes.)
> 
>                scripts/install-cm3-compiler.sh upgrade.
> 
>  From here, you are using the new compiler.
> 
>                scripts/do-cm3-<whatever-else-you-want>.sh buildship
> 
> That this works, starting with the previous release compiler, is my criterion
> for having removed bootstrap barriers.
> 
> 
> 
> > John
> >
> 
> -- 
> Rodney Bates
> rodney.m.bates at acm.org

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