[M3devel] upgrade fails with compilation error in m3quake

[Jay K]

I had written up something here.
 

 It is kind of embarassing, but there is also no perfect solution. 
 
 
 The rest of the computing world has had 64bit integers and 
 64 bit file sizes on 32bit platforms for 20+ years.  
 

 However, many 32bit platforms did make the same initial mistake 
 of having 32bit file sizes. 

 
 And when they fixed it, they generally left all source and binaries  
 having the same meaning, and all sources continuing to compile.
 
 
 And existing 32bit code would possibly error on large files, 
 or possibly work, depending on details. 
  

  And what they often did is introduce parallel interfaces.  
  For every:  
    SetFilePositio(int32) and GetFileSize:int32,  
  there is usually a   
  SetFilePosition(int64) and GetFileSize:int64.   

 
 Every one, and every wrapper library, gets to update their code. 
 And every library keeps both sets of function calls. 
 It is messy. 

 
 I believe there used to be 16bit interfaces as we well. 

 
 So what should we do?
  Introduce parallel interfaces? Tedious but compatible. Probably. 
  Ignore large files on 32bit platforms? Tempting but also embararassing. 
 
 
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.

 
 
 - Jay



 
> Date: Thu, 19 Nov 2015 22:52:11 +0100
> From: wagner at elegosoft.com
> To: rodney.m.bates at acm.org
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] upgrade fails with compilation error in m3quake
> 
> On Thu, 19 Nov 2015 15:03:00 -0600
> "Rodney M. Bates" <rodney_bates at lcwb.coop> wrote:
> 
> > It looks like a bootstrap barrier.  My installed compiler does not complain.
> > The first argument has type LONGCARD, declared at m3-libs/libm3/src/os/Common/File.i3:34
> > This was changed from CARDINAL in 2010, no doubt to handle big files on 32-bit systems.
> > The compiler was changed to allow this at similar time.
> > 
> > I made changes to the failing code in QScanner in June of 2014, but it would have had
> > the same failure even before.
> > 
> > I'm not sure of the easiest way to proceed.  Figuring out what the intermediate step
> > would be could be tedious.  You might consider just editing the type in File.i3
> > to CARDINAL temporarily, to build a compiler, then change it back and recompile with
> > that.  But then, there could possibly be other such problems.
> > 
> > But in general, we should have an upgrade procedure that anybody can use, starting with
> > the release compiler, and no such manual stuff.  I suppose trying to compile the
> > current libm3 before the current compiler is the source of the problem.  Can you easily
> > recompile the compiler with your old libraries?   We seem to have had some bootstrap
> > barriers that require doing the libraries before the compiler and others the other
> > way around, which makes having a general procedure problematic.
> 
> Perhaps I should give up on upgrading this old 32-bit FreeBSD system and
> just try to setup a current cm3 on another system at Elego. I just started
> it because there seemed to be a still working version.
> 
> It's probably not worth the efforts.
> 
> Thanks for your help anyway; I'll try to download something newer for booting
> from github.
> 
> Olaf
> 
> > Any ideas, Jay?
> > 
> > On 11/19/2015 01:42 PM, Olaf Wagner wrote:
> > > Anybody feels guilty?
> > > Or do I just need an intermediate step now to upgrade from a compiler
> > > from 2009?
> > >
> > > === package m3-sys/m3quake ===
> > >   +++ cm3 -build -DROOT='/home/wagner/work/cm3-github-ssh' $RARGS  && cm3 -ship $RARGS -DROOT='/home/wagner/work/cm3-github-ssh'  +++
> > > --- building in FreeBSD4 ---
> > >
> > > ignoring ../src/m3overrides
> > >
> > > new source -> compiling Quake.i3
> > > new source -> compiling QCompiler.i3
> > > new source -> compiling QCode.i3
> > > new source -> compiling QValue.i3
> > > new source -> compiling QVSeq.i3
> > > new source -> compiling QVTbl.i3
> > > new source -> compiling QVal.i3
> > > new source -> compiling QPromise.i3
> > > new source -> compiling QPromiseSeq.i3
> > > new source -> compiling QMachine.i3
> > > new source -> compiling QToken.i3
> > > new source -> compiling QIdent.i3
> > > new source -> compiling Quake.m3
> > > new source -> compiling QToken.m3
> > > new source -> compiling QIdent.m3
> > > new source -> compiling QScanner.i3
> > > new source -> compiling QScanner.m3
> > > "../src/QScanner.m3", line 47: VAL: first argument must be an INTEGER
> > > 1 error encountered
> > >
> > > Olaf
> > >
> > 
> > -- 
> > Rodney Bates
> > rodney.m.bates at acm.org
> 
> 
> -- 
> Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 
>                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
> Geschäftsführer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20151124/b2808701/attachment-0002.html>