<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'>I had written up something here.<BR> <BR><br> It is kind of embarassing, but there is also no perfect solution. <BR> <BR> <BR> The rest of the computing world has had 64bit integers and <br> 64 bit file sizes on 32bit platforms for 20+ years. <BR> <BR><br> However, many 32bit platforms did make the same initial mistake <br> of having 32bit file sizes. <BR><br> <br> And when they fixed it, they generally left all source and binaries <br> having the same meaning, and all sources continuing to compile.<BR> <BR> <BR> And existing 32bit code would possibly error on large files, <br> or possibly work, depending on details. <br> <BR><br> And what they often did is introduce parallel interfaces. <br> For every: <br> SetFilePositio(int32) and GetFileSize:int32, <br> there is usually a <br> SetFilePosition(int64) and GetFileSize:int64. <BR><br> <BR> Every one, and every wrapper library, gets to update their code. <br> And every library keeps both sets of function calls. <br> It is messy. <BR><br> <BR> I believe there used to be 16bit interfaces as we well. <BR><br> <BR> So what should we do?<BR> Introduce parallel interfaces? Tedious but compatible. Probably. <br> Ignore large files on 32bit platforms? Tempting but also embararassing. <BR> <BR> <BR>I'll try to look & see how bad the problem is of having parallel interfaces, so that existing code works, and new code can use "long" or "64" everywhere.<BR><br> <BR> <BR> - Jay<br><br><br><br> <BR><div>> Date: Thu, 19 Nov 2015 22:52:11 +0100<br>> From: wagner@elegosoft.com<br>> To: rodney.m.bates@acm.org<br>> CC: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] upgrade fails with compilation error in m3quake<br>> <br>> On Thu, 19 Nov 2015 15:03:00 -0600<br>> "Rodney M. Bates" <rodney_bates@lcwb.coop> wrote:<br>> <br>> > It looks like a bootstrap barrier. My installed compiler does not complain.<br>> > The first argument has type LONGCARD, declared at m3-libs/libm3/src/os/Common/File.i3:34<br>> > This was changed from CARDINAL in 2010, no doubt to handle big files on 32-bit systems.<br>> > The compiler was changed to allow this at similar time.<br>> > <br>> > I made changes to the failing code in QScanner in June of 2014, but it would have had<br>> > the same failure even before.<br>> > <br>> > I'm not sure of the easiest way to proceed. Figuring out what the intermediate step<br>> > would be could be tedious. You might consider just editing the type in File.i3<br>> > to CARDINAL temporarily, to build a compiler, then change it back and recompile with<br>> > that. But then, there could possibly be other such problems.<br>> > <br>> > But in general, we should have an upgrade procedure that anybody can use, starting with<br>> > the release compiler, and no such manual stuff. I suppose trying to compile the<br>> > current libm3 before the current compiler is the source of the problem. Can you easily<br>> > recompile the compiler with your old libraries? We seem to have had some bootstrap<br>> > barriers that require doing the libraries before the compiler and others the other<br>> > way around, which makes having a general procedure problematic.<br>> <br>> Perhaps I should give up on upgrading this old 32-bit FreeBSD system and<br>> just try to setup a current cm3 on another system at Elego. I just started<br>> it because there seemed to be a still working version.<br>> <br>> It's probably not worth the efforts.<br>> <br>> Thanks for your help anyway; I'll try to download something newer for booting<br>> from github.<br>> <br>> Olaf<br>> <br>> > Any ideas, Jay?<br>> > <br>> > On 11/19/2015 01:42 PM, Olaf Wagner wrote:<br>> > > Anybody feels guilty?<br>> > > Or do I just need an intermediate step now to upgrade from a compiler<br>> > > from 2009?<br>> > ><br>> > > === package m3-sys/m3quake ===<br>> > > +++ cm3 -build -DROOT='/home/wagner/work/cm3-github-ssh' $RARGS && cm3 -ship $RARGS -DROOT='/home/wagner/work/cm3-github-ssh' +++<br>> > > --- building in FreeBSD4 ---<br>> > ><br>> > > ignoring ../src/m3overrides<br>> > ><br>> > > new source -> compiling Quake.i3<br>> > > new source -> compiling QCompiler.i3<br>> > > new source -> compiling QCode.i3<br>> > > new source -> compiling QValue.i3<br>> > > new source -> compiling QVSeq.i3<br>> > > new source -> compiling QVTbl.i3<br>> > > new source -> compiling QVal.i3<br>> > > new source -> compiling QPromise.i3<br>> > > new source -> compiling QPromiseSeq.i3<br>> > > new source -> compiling QMachine.i3<br>> > > new source -> compiling QToken.i3<br>> > > new source -> compiling QIdent.i3<br>> > > new source -> compiling Quake.m3<br>> > > new source -> compiling QToken.m3<br>> > > new source -> compiling QIdent.m3<br>> > > new source -> compiling QScanner.i3<br>> > > new source -> compiling QScanner.m3<br>> > > "../src/QScanner.m3", line 47: VAL: first argument must be an INTEGER<br>> > > 1 error encountered<br>> > ><br>> > > Olaf<br>> > ><br>> > <br>> > -- <br>> > Rodney Bates<br>> > rodney.m.bates@acm.org<br>> <br>> <br>> -- <br>> Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com <br>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<br>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<br>> Geschäftsführer: Olaf Wagner | Sitz: Berlin<br>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<br>> _______________________________________________<br>> M3devel mailing list<br>> M3devel@elegosoft.com<br>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br></div> </div></body>
</html>