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

[Rodney M. Bates]

On 05/28/2015 05:15 PM, Rodney M. Bates wrote:
>
>
> On 05/28/2015 12:06 PM, Olaf Wagner wrote:
>> On Thu, 28 May 2015 17:56:20 +0200
>> John Marino <adacore at marino.st> wrote:
>>
>>> On 5/28/2015 17:01, Rodney M. Bates wrote:
>>>> 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.
>>>
>>> Olaf said, IIUC, that the current code can't be built by the last
>>> release compiler.  Putting aside that I believe that should be a hard
>>> requirement for the project, it sounds like maybe the last release can
>>> build it if the build order is fixed (e.g. a better upgrade.py script)?
>>>   It's not clear to me what the real situation is.
>>
>> No, this is a misunderstanding. I just said or tried to say that there
>> is no script (yet) that is smart enough to do all the things necessary to
>> build the current compiler on base of 5.8.6.
>>
>>>> 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.
>>
>> Rodney, have you really tried that? I'm not sure the steps above will
>> work. I had the feeling that we're missing some intermediate releases, but
>> I might be wrong there.
>>
>
> I have done it a number of times for AMD64_LINUX and LINUXLIBC6, using the
> last release compiler, and successfully building a development compiler,
> for several different development snapshots.  The last time was probably
> a few months ago, and I don't think much has happened in the compiler
> and library packages that would make them not compile.  It will take a
> me a little time, but I will try it again on these platforms.
>

OK, this is working for me on LINUXLIBC6.

With the release compiler installed:

$ cm3 -version
Critical Mass Modula-3 version 5.8.6
   last updated: 2010-04-11
   compiled: 2013-09-13 21:38:06
   configuration: /usr/local/cm3/bin/cm3.cfg
   host: AMD64_LINUX
   target: AMD64_LINUX

And a freshly pulled git repository from github,
in cm3/scripts:

1) $ ./do-cm3-all.sh realclean    #Clean everything
2) $ ./do-cm3-front.sh buildship  #Build a compiler & its support libraries

All compiles succeeded.

4) $ ./install-cm3-compiler.sh upgrade # Install the compiler

$ cm3 -version
Critical Mass Modula-3 version d5.10.0
   last updated: 2015-05-21
   compiled: 2015-05-29 02:54:41
   configuration: /usr/local/cm3/bin/cm3.cfg
   host: AMD64_LINUX
   target: AMD64_LINUX

Now repeat steps 1 and 2.  This will use the newly compiled head compiler.
to rebuild itself.  All compiles succeeded.

Finally, $./do-cm3-all.sh buildship  #Build the rest.

This compiles all the remaining stuff, none of which is involved in bootstrapping.
All compiles succeeded.

In the past, I often will install the second-time-compiled head compiler and
do it all a third time.  After getting this far, this has never failed, and
I didn't do it this time.

New package libunicode uses an addition to Compiler.i3 that is not in the release, so
you have to install the new compiler before compiling libunicode.





>>> My work takes place within a Makefile and moving things in /usr/local
>>> (for example) is actually illegal.  Now I could do all this manually for
>>> the purpose of building a new bootstrap, but as I mentioned in a
>>> previous post, it might be more effective to emulate what you guy have
>>> done: essentially build a series of bootstraps at strategic hashes until
>>> I've acquired a compiler that can build this (and then use that product
>>> as bootstrap for FreeBSD ports).
>>>
>>> If I did that approach, I could use a hint on the hashes to try...
>>
>> We should be able to script something that sets up the current compiler
>> at least on a given specific platform with a well-defined environment.
>> I might be able to offer more help in the second week of June, if you
>> can wait until then.
>>
>> Olaf
>>
>

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