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

[Rodney M. Bates]

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.

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