<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> cm3/cm3cg are more special than the others, because cm3 is statically linked. <br> There is no m3core.dll, that cm3 uses, or m3quake.dll, etc. <br> There is m3core.dll, but cm3 doesn't uses it. <br> Shipping it doesn't affect the in-use cm3. </div><div><br></div><div><br> If/when we fix this, in fact, we can stop doing that static linking. <br> It makes sense for m3quake, etc. as there are few/no other users. <br> But for libm3/m3core, it'll provide a nice size optimization. </div><div><br></div><div><br> The mutual incompatibilty between old/new cm3/cm3cg is perfectly ok. <br> It is meant to be dealt with, not avoided.</div><div><br></div><div><br> I believe upgrade.py did deal with this correctly, but this environment <br> variable required to quash shipping of cm3cg broke it. </div><div><br></div><div><br> The environment variable change really should imho be removed from cm3cg. <br> Please. </div><div><br></div><div><br> And then we can switch to "destdir" and remove all the in place updating, perhaps. </div><div><br></div><div><br> Or I need to update upgrade.py to ship cm3cg itself. <br> I guess I'll do that. </div><div><br></div><div><br></div><div>upgrade.py may not have worked for you, but I have used it many many times.</div><div>It worked. But currently it is probably broken by the m3cc/src/m3makefile change.</div><div>I'll update it to accommodate that change..</div><div><br></div><div><br></div><div>And upgrade.sh I believe was in heavy use by Hudson.</div><div><br></div><div><br> - Jay<br><br><br><br></div><div>> Date: Fri, 29 May 2015 16:10:41 -0500<br>> From: rodney_bates@lcwb.coop<br>> CC: m3devel@elegosoft.com<br>> To: <br>> Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110<br>> <br>> Yes, we could have a better organization. I agree, the principal way<br>> should be to build a complete set of everything that matters to the<br>> implementation of the language, them replace them all at once. A<br>> separate DESTDIR or such is needed.<br>> <br>> The set, as Jay points out, is larger than just cm3 and m3cc. It includes<br>> at least m3core, probably libm3, and cm3, the executable depends on several<br>> separately built packages--cm3, m3middle, m3front, m3quake, m3makefile, etc.<br>> <br>> In general, we can't really assume anything about the kinds of dependencies<br>> of one package on old or new versions of another. Right now, cm3 and m3cc<br>> are known mutually incompatible between 5.8 and the head, because the numbering<br>> in M3CG_Binary.i3 has changed. We could probably establish some coding rules and<br>> order-of-install rules that would allow a newer m3cc to work with an older cm3,<br>> but that's only one pattern.<br>> <br>> I once thought do-cm3-*.sh build would do what we are talking about, but it<br>> if I remember right, puts every package into immediate use as it is built<br>> and also uses overrides, which keeps things inside the source tree, but makes<br>> it unshippable. So I always use buildship. This has never, to my knowledge<br>> run afoul of any compatibility problem other than between cm3 and m3cc, but it<br>> does ship every package besides these two as it is built, so the potential<br>> is there.<br>> <br>> I haven't had the energy to even try to understand just what the upgrade<br>> scripts do, but they have not treated me well. If I had done different<br>> patterns of incompatible changes, they would probably have been better<br>> than the procedure I use.<br>> <br>> On 05/29/2015 01:06 PM, Jay K wrote:<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>> > [please pardon my editing...]<br>> ><br>> ><br>> > I see what you mean that cm3cg is an independent node in the graph and can be built in any order,<br>> > but, I guess, the story is/was, you have to know the safe order to ship things.<br>> ><br>> ><br>> > It is encoded in pkginfo.txt and the Python scripts honor it..though they don't always use pkginfo.txt for their ordering..<br>> > And encoding the dependency graph there isn't ideal. It is really encoded in the import declarations<br>> > in the m3makefiles, usually, but not in this case...<br>> ><br>> ><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.<br>> > But perhaps it isn't strictly enforced enough.<br>> ><br>> ><br>> ><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.<br>> ><br>> ><br>> > update.py handled it.<br>> ><br>> ><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.<br>> ><br>> ><br>> > Let me draw a close analogy.<br>> ><br>> ><br>> > In the slightly larger software world we have:<br>> ><br>> > make<br>> > make install<br>> > make install DESTDIR=somewhere_new<br>> ><br>> ><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".<br>> ><br>> ><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)<br>> ><br>> ><br>> > Don't do a "rolling upgrade". Don't install each package as it is built. No package, no cm3,<br>> > not cm3cg, nothing.<br>> ><br>> ><br>> > I'm basically suggesting that.<br>> ><br>> ><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.<br>> ><br>> ><br>> > If you say, "almost don't ever ship, but provide a way to", that is almost the same.<br>> ><br>> ><br>> > make-dist.py follows the make install DESTDIR way.<br>> ><br>> > 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? :)<br>> ><br>> ><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.<br>> ><br>> ><br>> > Again I suggest it be looked into, and maybe be promoted as basically<br>> > the replacement for upgrade.py and upgrade.sh.<br>> ><br>> ><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.<br>> ><br>> ><br>> > Anyway, I have no time lately, just email. :(<br>> ><br>> ><br>> > - Jay<br>> ><br>> ><br>> ><br>> > > 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>> <br>> -- <br>> Rodney Bates<br>> rodney.m.bates@acm.org<br></div> </div></body>
</html>