<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>new source -> compiling Cstdlib.i3<BR>"..\src\C\32BITS\BasicCtypes.i3", line 18: illegal based LONGINT literal, zero used<BR>"..\src\C\32BITS\BasicCtypes.i3", line 18: illegal based LONGINT literal, zero used<BR><BR>
long_long = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];<BR><BR>
<BR>
Why isn't this LONGINT? So that NT386 can limp along? And it'd be correct for the rest, eh?<BR>
I'll try it and see..<BR>
<BR>
The underlying system (the compiler) has (U)Int[8,16,32,64]<BR>
They should just be used here imho..<BR>
<BR>
Also, what should "long" be on 64bit?<BR>
On Windows it is 32 bits always.<BR>
On 32 bit systems it is 32 bits.<BR>
I think the 64bits directory is going to be forked for AMD64_NT_*.<BR>
The Windows decision imho has successfully been applied to more code and more users so therefore is better by practical success, even if the whole issue is problematic almost no matter what. Clearly the C and Modula-3 notions of integers are pretty poor..<BR>
<BR>
- Jay<BR><BR><BR>
<HR id=stopSpelling>
<BR>
> Date: Mon, 14 Apr 2008 08:52:52 +0200<BR>> From: wagner@elegosoft.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] cm3 regression<BR>> <BR>> Quoting Olaf Wagner <wagner@elegosoft.com>:<BR>> <BR>> > Building of libm3 now fails even in release-builds with<BR>> ><BR>> > 4539 new source -> compiling SocketPosix.m3<BR>> > 4540<BR>> > 4541 NEXT Fatal Error: bad version stamps: SocketPosix.m3<BR>> > 4542<BR>> > 4543 version stamp mismatch: Compiler.Platform<BR>> > 4544 <df3c2b13d1d385ee> => SocketPosix.m3<BR>> > 4545 <a731334c763badf8> => Compiler.i3<BR>> > 4546 version stamp mismatch: Compiler.ThisPlatform<BR>> > 4547 <92d2f58d2092154f> => SocketPosix.m3<BR>> > 4548 <eadfedd2877a3d59> => Compiler.i3<BR>> > 4549 NEXT *** execution of cm3 -build<BR>> > -DROOT=?/home/m3/work/cm3-ws/birch.elegosoft.com-2008-04-14-00-00-03/cm3?<BR>> > -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700?<BR>> > -DCM3_LAST_CHANGED=?2008-03-16? && cm3 -ship<BR>> > -DROOT=?/home/m3/work/cm3-ws/birch.elegosoft.com-2008-04-14-00-00-03/cm3?<BR>> > -DCM3_VERSION_TEXT=?d5.7.0? -DCM3_VERSION_NUMBER=?050700?<BR>> > -DCM3_LAST_CHANGED=?2008-03-16? failed ***<BR>> > 4550 compile return value: 0<BR>> > 4551 [end compile 2008.04.14 02:54:34]<BR>> > 4552 *** COMPILE FAILED<BR>> ><BR>> > Does anybody understand what's going on?<BR>> > During upgrade(), libm3 should only be built _after_ the new compiler<BR>> > has been installed, at least that is the intention.<BR>> ><BR>> > I'm in a hurry, so if anybody else cares to fix this, it would be great.<BR>> <BR>> I sent that mail too fast. It seems that only I386_DARWIN fails in<BR>> the release-build, but for other reasons. The last-ok builds can<BR>> be expexted to fail after incompatible changes in the runtime.<BR>> So this should cure itself during the next days.<BR>> <BR>> We should however note that we need a full compiler bootstrap again<BR>> even from older d5.7.0 archives now to compile current sources.<BR>> <BR>> Olaf<BR>> -- <BR>> Olaf Wagner -- elego Software Solutions GmbH<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>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<BR>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>> <BR><BR></body>
</html>