<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'> > was looking several alternative places for an executable cm3cg<BR> <BR>I agree it did/does do that.<BR>I did put that in.<BR>I thought it was a good idea at the time.<BR>I realize now it is a mistake.<BR>If that behavior is still present, it will be advisable also to<BR>first update one's config to stop doing that.<BR> <BR> <BR>Basically, "ship" is a very carefully ordered operation, the shipping<BR>of multiple packages.<BR>If you have no bugs, and you ship in the correct order, then you don't need DESTDIR.<BR>IF you have no bugs, but you ship in the incorrect order, you cause a bad mixing of things.<BR>If you use "DESTDIR" then you can ship safely in any order and do some switch<BR>at the end, such as by reseting PATH to point to the new set of files.<BR>If you have circular dependencies, there might not be a workable order.<BR> <BR> <BR>I agree this could be the case.<BR>make-dist.py is written to avoid but might be slightly wrong.<BR> <BR> <BR>I suspect I only ever ran make-dist after upgrade.<BR> <BR> <BR>I have started setting up VMs..though NetBSD, FreeBSD, OpenBSD all fail<BR>under VirtualBox if Hyper-V is enabled...but at least Debian is making progress.<BR> <BR> <BR>So hopefully I can test and fix this properly soon.<BR>And then I'll back to using the C backend anyway. :)<BR> <BR> <BR> - Jay<br><br><br> <BR><div>> Date: Sun, 31 May 2015 14:13:46 -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>> The error message you keep getting pretty certainly means it is running a<br>> new cm3cg with an old cm3. And it consistently happens immediately after<br>> cm3cg is rebuilt.<br>> <br>> The build of cm3cg (package m3cc) appears to be the first use of cm3 in all<br>> your failed builds, and I don't think that package would ever run cm3cg, as<br>> there is no Modula-3 code in it. Which means there is no proof that the<br>> version of cm3cg that would have been used before it was rebuilt is the old<br>> one. (Could it be a new one left over from a previous incomplete build?)<br>> <br>> One experiment that would prove this would be, in the state your are<br>> starting from before trying a full build, try any means of running<br>> cm3 on a package that contains Modula-3 code, to see if it avoids the<br>> recurring problem.<br>> <br>> But I have another theory. I don't know what this ports bootstrap<br>> is, but there was a time when things where set up so that cm3, instead<br>> of looking in just the same directory as its own executable was found,<br>> was looking several alternative places for an executable cm3cg. This<br>> caused the same problem to occur in a different way. Even when the<br>> newly rebuilt cm3cg executable was not copied to the bin directory<br>> right away, its mere existence where it was built was causing it to<br>> be found the next time cm3 started up, leading to the same failure.<br>> <br>> I don't remember how this was fixed, but either Jay or I did something<br>> about it. Perhaps the ports bootstrap was made during a time when this<br>> behavior was happening.<br>> <br>> On 05/31/2015 02:41 AM, John Marino wrote:<br>> > On 5/29/2015 20:43, John Marino wrote:<br>> >> On 5/29/2015 20:15, Olaf Wagner wrote:<br>> >>><br>> >>> Well, yes, I understand that. I would have tried your exact setup,<br>> >>> but I have no system available to test that on.<br>> >>><br>> >>> At least I have validated that based on the origianl 5.8.6 installation<br>> >>> archive for AMD64_FREEBSD you can build the new compiler from the current<br>> >>> sources with a simple call of the upgrade.sh script. which I still doubted<br>> >>> yesterday.<br>> >><br>> >><br>> >> The card I still have left to play is to extract the bootstrap, let it<br>> >> overwrite itself per Rodney's technique and then build the real compiler<br>> >> (dumping the whole "intermediate" area).<br>> ><br>> > FWIW, this did not work either. Rodney's technique doesn't seem to work<br>> > with the ports bootstrap. I don't know why it would work with provided<br>> > 5.8.6 but not rebuilt one. As far as I can tell, I did what he said<br>> > would always work.<br>> ><br>> > I'm at a loss as to where to go from here. It's starting to look like I<br>> > have to throw away the ports 5.8.6 bootstrap and start over somehow. I<br>> > don't think it should be this hard. :(<br>> ><br>> > John<br>> ><br>> <br>> -- <br>> Rodney Bates<br>> rodney.m.bates@acm.org<br></div> </div></body>
</html>