<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> > Also, this script built the compiler before the support libraries m3core and<br> > libm3. I think there may have been one bootstrap scenario where this was the<br> > way it needed to be done, but usually it is the other way around--these two<br> > libraries first.</div><div><br></div><div><br> This is very deliberate and should always work, when doing a native upgrade. <br> It is true it is not always required. <br> When doing a "clean" cross build, it is true that it is backwards. <br> It is required when upgrading from an older build. </div><div><br></div><div><br> Native upgrades start at least with a working compiler and its matching runtime.<br> Cross builds start with a working host compiler and nothing for the target -- so they do start with m3core.</div><div><br></div><div><br> The idea that people don't get right away is that the compiler <br> and runtime are very coupled. A compiler targets a particular runtime.<br> Its output requires a certain runtime.</div><div><br></div><div><br> Look at RT0.i3 in particular.<br> We haven't changed that in over 10 years, but Critical Mass did.<br> For example.</div><div><br></div><div><br> Or if you change the size of WIDECHAR. </div><div><br></div><div><br> The compiler outputs data that the garbage collector uses. <br> The compiler outputs function calls that are to functions in m3core.</div><div><br></div><div> <br> The coupling to libm3 is less clear to me, but the coupling to m3core is significant.</div><div><br></div><div> <br> m3core is kind of the lowest level runtime that compiler pretty much unavoidably requires to be with its output. </div><div><br></div><div><br> Perhaps if you write code w/o any traced types and without try/finally or raise, you can avoid m3core. But there<br> is still module initialization and running "main". So m3core is unavoidable.</div><div><br></div><div><br> In the Unix world, consider like crtstart.o.<br> In the Windows world, consider that main is called from mainCRTStartup and this is like wherever that is.<br> (Or DllMain is called from DllMainCRTSTartup, WinMain is called from WinMainCRTStartup, etc.<br> There is an analog between DllMain and the entry points of each module other than Main.)</div><div><br></div><div><br> libm3 is more a convenience library that you can maybe possibly do without.<br> Consider this, like, not the startup code, but stdio, stdlib, STL, etc.</div><div><br></div><div><br> Another dependency people don't understand is between the frontend and the backend. The gcc backend in particular.<br> When you change the "M3CG", the persisted IR, these two have to be updated together.</div><div><br></div><div><br> Again, these things don't change much, so we get away without worrying about and without automating it and without people understanding it.</div><div><br></div><div><br> We changed this, for example, when the atomics were added.<br> I think I made changes too.</div><div><br></div><div><br> I believe I automated this, but then wimped out and commented out one line. I'll report back later on this. <br> I didn't want to diverge from the shell scripts, perhaps.</div><div><br></div><div><br> I'll try to find some time here.<br> I agree an upgrade from 5.8.6 to current is desirable.<br> I go back and forth on this. I have likely broken it, and fixed it.<br> For example, the mklib dependency on the Win32 headers. That should be ok now.<br> For another potential example, the frontend can't use LONGINT until a release has it. But I think we have that now.</div><div><br></div><div><br> We do not support going arbitrarily back, but the previous release is a good target.<br> I have at times gone further back and fixed things up. </div><div><br></div><div><br> You can also bootstrap via the cross mechanism even if you aren't crossing, but I suppose that is too difficult. </div><div><br></div><div> Here:</div><div><br></div><div> https://github.com/modula3/cm3/blob/master/scripts/python/upgrade.py <br>51 # <br>52 # ... and continue with the backend, if needed <br>53 # <br>54 <br> <br>55 a = Root + "/m3-sys/m3cggen/" + Target + "/m3cggen > " + Root + "/m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h" <br>56 print(a) <br><b>57 # os.system(a) <br></b>58 FilterPackages([ "m3cc" ]) and DoPackage(argv_BuildShip, [ "m3cc" ]) </div><div><br></div><div><br>uncomment out line 57.<br>That is where I wimped out. That line should be there.<br>Hopefully it is still correct.</div><div>It is a little gross in that it outputs into the source tree.</div><div><b>This really shouldn't be needed if you build correctly</b> from a consistent checkout<b>. It is only for when you have local edits.</b></div><div>Even bootstrap/upgrade should not require it. The output should just match what is already there.</div><div><br></div><div><br>And another thing: When I wrote upgrade.py, I thought I was mimicking upgrade.sh, and I mostly was.<br>One thing I missed though was that upgrade.sh does actually build the entire system, whereas upgrade.py<br>only builds the compiler.</div><div><br></div><div><br> So consider this, somewhat overkill instead: </div><div><br></div><div> cd scripts<br> ./upgrade.py && ./do-cm3-all.py realclean skipgcc && ./do-cm3-all buildship skipgcc </div><div><br></div><div><br> Also note that in-place updates are done while it goes. Certain errors force a need to go backwards.</div><div><br></div><div> So you should maintain a backup of the minimum -- cm3, cm3.cfg, config directory, m3core, libm3, cm3cg.<br> Or be able to restore from a release.</div><div><br></div><div><br> That list is important, so I'll repeat: cm3, cm3.cfg, config directory in newer releases (cm3.cfg delegages to it), m3core, libm3, cm3cg (optional). </div><div><br></div><div><br></div><div><br></div><div> To put this another way: consider the compiler itself to be a very portable and minimalist Modula-3 program.<br> It has few dependencies and does most things itself.</div><div><br></div><div><br> Consider the C program that just uses very little of the standard library but does use printf("main").</div><div><br></div><div><br> What do you need to build such things? You don't need, you know, a marshaling library, a windowing library etc.,<br> but you need a working compiler, frontend, backend, assembler, linker, and a minimal library</div><div><br></div><div><br> That is what is required to a native upgrade.</div><div><br></div><div> </div><div><br></div><div> - Jay<br><br><br><br><br></div><div>> Date: Thu, 28 May 2015 10:01:21 -0500<br>> From: rodney_bates@lcwb.coop<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110<br>> <br>> <br>> On 05/28/2015 06:49 AM, John Marino wrote:<br>> > I got stuck again trying to build the latest on FreeBSD.<br>> ><br>> > 1. tar extracted to working directory along with a bootstrap compiler<br>> > 2. CM3 and CM3_INSTALL defined in environment<br>> > 3. executed scripts/python/upgrade.py<br>> ><br>> > result:<br>> > http://leaf.dragonflybsd.org/~marino/m3.log<br>> ><br>> > I could guess that something is picking up a bootstrap component instead<br>> > of a newly built one.<br>> <br>> Yes.<br>> <br>> >> m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110<br>> <br>> means it is trying to compile using a new cm3cg backend and an old cm3 front end.<br>> I just added this error message after Olaf had this problem. (Otherwise it would<br>> have failed anyway, but with a less informative message.)<br>> <br>> > I guess it's trying to build the c backend?<br>> ><br>> <br>> It finished the C backend and was trying to build m3core, using the inconsistent<br>> compiler. Usually, neither cm3 nor cm3cg is copied to the bin directory,<br>> even when doing a ship, in order to avoid this, which is an exception. For all<br>> other executables, ship copies them to the bin directory. The shell script<br>> scripts/install-cm3-compiler.sh is then run manually, after both cm3 and cm3cg<br>> are compiled, to copy them to bin atomically (sort of).<br>> <br>> I don't know why that happened. I don't have experience with the Python scripts.<br>> <br>> Jay?<br>> <br>> Also, this script built the compiler before the support libraries m3core and<br>> libm3. I think there may have been one bootstrap scenario where this was the<br>> way it needed to be done, but usually it is the other way around--these two<br>> libraries first.<br>> <br>> <br>> > Am I doing some kind of obvious mistake?<br>> ><br>> <br>> No, it's a bootstrap barrier. These pop up somewhat regularly. We all usually<br>> just build from the most recent development build, which works for getting new<br>> things tried out initially. But we need to make a habit of regularly rebuilding<br>> from the previous release to flush these out.<br>> <br>> You might try scripts/do-cm3-front.sh realclean<br>> scripts/do-cm3-front.sh buildship<br>> <br>> (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg at this point.<br>> The step below does it somewhat redundantly, but only one level, unless the<br>> version number changes.)<br>> <br>> scripts/install-cm3-compiler.sh upgrade.<br>> <br>> From here, you are using the new compiler.<br>> <br>> scripts/do-cm3-<whatever-else-you-want>.sh buildship<br>> <br>> That this works, starting with the previous release compiler, is my criterion<br>> for having removed bootstrap barriers.<br>> <br>> <br>> <br>> > John<br>> ><br>> <br>> -- <br>> Rodney Bates<br>> rodney.m.bates@acm.org<br></div> </div></body>
</html>