[M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110
Jay K
jay.krell at cornell.edu
Fri May 29 20:06:11 CEST 2015
> I don't see an easy way to make the variable work, as there is no
> constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh
> happens to do cm3cg first, but that is not necessarily required.
[please pardon my editing...]
I see what you mean that cm3cg is an independent node in the graph and can be built in any order,but, I guess, the story is/was, you have to know the safe order to ship things.
It is encoded in pkginfo.txt and the Python scripts honor it..though they don't always use pkginfo.txt for their ordering..And encoding the dependency graph there isn't ideal. It is really encoded in the import declarationsin the m3makefiles, usually, but not in this case...
The way that works is to build but don't ship cm3cg.
Then ship cm3cg.
Then copy cm3.
Then use the new cm3. But perhaps it isn't strictly enforced enough.
I used do this fairly often.
Though breaking changes in cm3cg were rare, granted.
But I'd also occasionally bootstrap from an older release.
I'll have to try to do that again soon -- actually make the current
tree easily buildable from the last release.
update.py handled it.
I'm on the fence.
"buildship" of multiple packages is in general problematic.
I kinda think the whole mechanism needs to be revampled.
Let me draw a close analogy.
In the slightly larger software world we have:
make
make install
make install DESTDIR=somewhere_new
buildship is equivalent make && make install, or a make install that includes the make part,
as they sometimes do.
Read up on building glibc and they point out how dangerous this is -- how dangerous make install is w/o DESTDIR.
We have the same danger on a smaller scale.
You aren't going to break the "OS", but you can break "cm3".
The safe recommendation is make install DESTDIR.
Basically "install" "everything" "on the side", get it all installed, multiple
"packages", then copy or tar/untar it all. Or chroot into it and test it out, and
then do an in-place update. Or swap into the chroot and never return? (tail call install)
Don't do a "rolling upgrade". Don't install each package as it is built. No package, no cm3,
not cm3cg, nothing.
I'm basically suggesting that.
Now, if you say "don't ever ship, but somehow otherwise manually copy", well
that does kind of resolve to the same thing.
If you say, "almost don't ever ship, but provide a way to", that is almost the same.
make-dist.py follows the make install DESTDIR way.
It is "better" I guess because I wrote it later, and because I was following
the example of the other .sh files that make distributions. So blame/credit Olaf? :)
It starts with a working compiler, copies parts into /temp, builds a new compiler into /tmp, and
uses what it builds to build everything.
Again I suggest it be looked into, and maybe be promoted as basically
the replacement for upgrade.py and upgrade.sh.
upgrade.py could wrap it and do the final steps of copy/untar in-place.
Or make-dist.py could just print the last optional command.
Anyway, I have no time lately, just email. :(
- Jay
> Date: Fri, 29 May 2015 11:35:41 -0500
> From: rodney_bates at lcwb.coop
> To: adacore at marino.st; wagner at elego.de
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110
>
> Setting INSTALL_CM3_IN_BIN=yes is what forces the premature install of cm3cg.
> I see I had encountered this problem two years ago, but then it was happening
> regardless of the value of this variable. My fix only addresses the case when
> the variable is not set. I naively went to extra trouble to preserve the
> existing behavior when it is set--obviously not right.
>
> I don't see an easy way to make the variable work, as there is no
> constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh
> happens to do cm3cg first, but that is not necessarily required.
>
> So INSTALL_CM3_IN_BIN is broken and hard to fix, if the two need
> compatible upgrades. For now, it looks like install-cm3-compiler.sh
> is the only working way.
>
> But maybe John and Olaf have found a different way around this.
>
> On 05/29/2015 10:55 AM, Rodney M. Bates wrote:
> > I don't know yet why, or what needs to change, but here is definitely the problem, starting
> > in line 4575 of your m3c log:
> >
> >
> > g++48 -O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc48 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a
> > gmake[1]: Leaving directory `/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc/AMD64_FREEBSD/gcc'
> >
> >
> > This is copying the newly-built cm3cg (the compiler back end) to your
> > bin directory:
> >
> > Forced ship of cm3cg.
> > --- shipping from AMD64_FREEBSD ---
> >
> > . => /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin
> > cm3cg
> > ==> m3-sys/m3cc done
> >
> > === package m3-libs/m3core ===
> >
> > And this is using the cm3 (compiler front end) that was already in the bin
> > directory, and is the release version.
> >
> > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -build -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' $RARGS && /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship $RARGS -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' +++
> > --- building in AMD64_FREEBSD ---
> >
> > ignoring ../src/m3overrides
> >
> > new source -> compiling RTHooks.i3
> >
> > This is cm3cg (aka m3cgc1) detecting the incompatibility:
> >
> > m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110
> > compilation terminated.
> >
> > Here is the counterpart section of my log:
> >
> > g++ -g -O2 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a
> >
> > On my build, it's not shipping:
> >
> > Not shipping cm3cg.
> > --- shipping from AMD64_LINUX ---
> >
> > missing ".M3SHIP" file, build the package first.
> > ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3cc done
> >
> > === package /home/rodney/proj/m3/git/cm3/m3-libs/m3core ===
> > +++ cm3 -build -DROOT='/home/rodney/proj/m3/git/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/rodney/proj/m3/git/cm3' +++
> > --- building in AMD64_LINUX ---
> >
> > ignoring ../src/m3overrides
> >
> > new source -> compiling RTHooks.i3
> > new source -> compiling RT0.i3
> >
> > When it works, the copying of both cm3 and cm3cg to the bin directory is delayed until after both have been
> > built, in the 'install-cm3-compiler.sh upgrade' step.
> >
> > I see your build is using a full path to the bin directory and mine is letting
> > it come from the usual $PATH search, but that should make no difference, as long
> > as the bin directory is found in a consistent way, which seems to be the case
> > in both builds.
> >
> >
> >
> > On 05/29/2015 04:51 AM, John Marino wrote:
> >> On 5/29/2015 11:39, Olaf Wagner wrote:
> >>> On Fri, 29 May 2015 11:10:50 +0200
> >>> John Marino <adacore at marino.st> wrote:
> >>>
> >>>> On 5/29/2015 10:54, Olaf Wagner wrote:
> >>>>> Please try what I suggested in the attached mail: define
> >>>>> INSTALL_CM3_IN_BIN=yes
> >>>>> in the environment and see if that helps.
> >>>>>
> >>>>
> >>>> Unfortunately it seems the result is exactly the same, even when
> >>>> INSTALL_CM3_IN_BIN is defined in the environment.
> >>>
> >>> Can I see the new logs? Has the new backend (cm3cg) been installed now?
> >>>
> >>
> >> It's here:
> >> http://leaf.dragonflybsd.org/~marino/m3c.log
> >>
> >> It never completes "do-cm3-front.sh buildship "
> >>
> >> Note that I'm using a bootstrap install and set INSTALL_ROOT to another
> >> location, but it never gets to the point of installing anything.
> >>
> >> John
> >>
> >
>
> --
> Rodney Bates
> rodney.m.bates at acm.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150529/6d504cdd/attachment-0002.html>
More information about the M3devel
mailing list