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