Re: [fpc-pascal] fpc 2.2.0 win32_arm-linux cross-compiler issue
On 26/09/2007, Peter Vreman <[EMAIL PROTECTED]> wrote: > > > Hi all, > > I have downloaded the freepascal 2.2.0 fpc source code ( > > fpcbuild-2.2.0.zip) and attempted to create a arm-linux cross-compiler > that > > runs under win32. I have done this previously with the fpcbuild-2.0.4.zip > > file ok using this batch file: > > > > **START OF BATCH FILE > > set path=G:\fpc\2.2.0\bin\i386-win32 > > make distclean > > > > make all install CPU_TARGET=arm OS_TARGET=linux > > CROSSBINDIR=G:\fpc-crossbinutils\arm-linux BINUTILSPREFIX=arm-linux- > > INSTALL_PREFIX=G:\fpc_win32_arm-linux COMPILER_OPTIONS="cpufpemu" > > > > pause > > END OF BATCH FILE** > > > > > > After I build the cross-compiler and tried using 'ppcrossarm.exe' to > build a > > pascal program I was having errors in the output and noticed this: > > > > Free Pascal Compiler version 2.2.0 [2007/09/24] for arm > > Copyright (c) 1993-2007 by Florian Klaempfl > > Target OS: WinCE for ARM > > > > I am using the same batch file to compile my pascal program that I used > > before so I am unsure why it is saying that the Target OS: WinCE for ARM > is > > coming up :( > > WinCE is the default ARM target if a cross compiler is build under > Windows. You need to specify > -Tlinux on the commandline or add it to fpc.cfg to make it the default: > > #ifdef cpuarm > -Tlinux > #endif > > Thanks Peter that addition to the fpc.cfg worked! :) I am not sure why I didn't need that before thoughI was previously using: -XParm-linux- in the fpc.cfg file like so: #IFDEF GP2X # -Ce # -CfSOFT # -CfLIBGCC -XS # -XD -Xd -XParm-linux- #ifdef cpuarm -Tlinux #endif -Fug:\FPC_win32_arm-linux\units\arm-linux\* -Flg:\devkitGP2X\arm-linux\lib -Flg:\devkitGP2X\arm-linux\lib\ldscripts -Flg:\devkitGP2X\lib -Flg:\devkitGP2X\lib\gcc\arm-linux\4.0.2 -Flg:\devkitGP2X\lib\pkgconfig -Flg:\devkitGP2X\sysroot\lib -Flg:\devkitGP2X\sysroot\usr\lib -Flg:\devkitGP2X\sysroot\usr\lib\gconv # -Flg:\Fpc\2.0.4\lib\arm-linux\lib # -Flg:\Fpc\2.0.4\lib # -Flg:\Fpc\2.0.4\lib\sysroot\lib # -Flg:\Fpc\2.0.4\lib\sysroot\usr\lib # SOFT LIBGCC FPA FPA10 FPA11 VFP #ENDIF cheers, Paul ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpc 2.2.0 win32_arm-linux cross-compiler issue
On 26/09/2007, Peter Vreman <[EMAIL PROTECTED]> wrote: > > > WinCE is the default ARM target if a cross compiler is build under > Windows. You need to specify > -Tlinux on the commandline or add it to fpc.cfg to make it the default: > > #ifdef cpuarm > -Tlinux > #endif > > Sorry, ignore the #ifdef cpuarm -Tlinux #endif in my previous post...I was using the fpc.cfg without that new addtion :) cheers, Paul ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] more questions on storage
On Wed, 26 Sep 2007 16:29:20 +0200 (CEST)
[EMAIL PROTECTED] (Marco van de Voort) wrote:
> > Am Mittwoch, den 26.09.2007, 13:24 +0200 schrieb Marco van de Voort:
> > > > >
> > > > > Ansistrings (and thus {$longstrings on}) work fine.
> > > >
> > > > Ah, okay. The Fog is lifting fastly. :)
> > > >
> > > > And AnsiStrings are pretty much compatible to C's char*. Very
> > > > handy.
> > >
> > > Yes, though ansistrings may contain #0's.
> >
> > Interesting, how will a cast handle this case?
>
> > Will it change the intermediate #0 to something else or will the
> > resulting pchars be cut at first occurrence?
>
> A cast is really a cast. IOW the cast pchar(ansistring) is mostly a
> no-op. Traditional C code then usually treats the #0 as end of
> string.
PChar(AnsiString) was a no-op typecast in the past and is nowadays a
function. It checks whether the AnsiString is nil and if yes returns a
pointer to a string containing one character: #0.
That means:
Pointer(AnsiString) <> Pointer(PChar(AnsiString))
To get a no-op typecase you can use:
MyPChar:=PChar(Pointer(AnsiString));
> It's mostly important when ansisstring is abused as general purpose
> buffer, but generally it is better to use dyn arrays for that.
Mattias
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] more questions on storage
> [EMAIL PROTECTED] (Marco van de Voort) wrote: > > A cast is really a cast. IOW the cast pchar(ansistring) is mostly a > > no-op. Traditional C code then usually treats the #0 as end of > > string. > > PChar(AnsiString) was a no-op typecast in the past and is nowadays a > function. It checks whether the AnsiString is nil and if yes returns a > pointer to a string containing one character: #0. > > That means: > Pointer(AnsiString) <> Pointer(PChar(AnsiString)) > > To get a no-op typecase you can use: > MyPChar:=PChar(Pointer(AnsiString)); Is this delphi compat, and if yes, what is this exactly for? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] more questions on storage
On Thu, 27 Sep 2007, Marco van de Voort wrote: > > [EMAIL PROTECTED] (Marco van de Voort) wrote: > > > A cast is really a cast. IOW the cast pchar(ansistring) is mostly a > > > no-op. Traditional C code then usually treats the #0 as end of > > > string. > > > > PChar(AnsiString) was a no-op typecast in the past and is nowadays a > > function. It checks whether the AnsiString is nil and if yes returns a > > pointer to a string containing one character: #0. > > > > That means: > > Pointer(AnsiString) <> Pointer(PChar(AnsiString)) > > > > To get a no-op typecase you can use: > > MyPChar:=PChar(Pointer(AnsiString)); > > Is this delphi compat, and if yes, what is this exactly for? It is Delphi compatible. PChar(AnsiString) Will always point to a null-terminated string. If the string is empty (which means the pointer value is Nil), a pointer to a pre-defined null-terminated string is returned. In other words: you always get a non-nil value. On the other hand: Pointer(AnsiString) Returns Nil if the string is empty. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] more questions on storage
On Thu, 27 Sep 2007 12:38:13 +0200 (CEST) [EMAIL PROTECTED] (Marco van de Voort) wrote: > > [EMAIL PROTECTED] (Marco van de Voort) wrote: > > > A cast is really a cast. IOW the cast pchar(ansistring) is mostly > > > a no-op. Traditional C code then usually treats the #0 as end of > > > string. > > > > PChar(AnsiString) was a no-op typecast in the past and is nowadays a > > function. It checks whether the AnsiString is nil and if yes > > returns a pointer to a string containing one character: #0. > > > > That means: > > Pointer(AnsiString) <> Pointer(PChar(AnsiString)) > > > > To get a no-op typecase you can use: > > MyPChar:=PChar(Pointer(AnsiString)); > > Is this delphi compat, and if yes, what is this exactly for? I don't know. The change broke some lazarus code and now it is polluted by the ugly double type casts, just to get some no-op type casts. Because this fact is not widely known or often forgotten, many use the PChar() as simple type cast. That's why the lcl interfaces already got into troubles several times, so everytime we get strange errors I first search for these typecasts. Maybe we should mention this fact at a more prominent place in the wiki and docs. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] more questions on storage
Mattias Gaertner wrote: On Thu, 27 Sep 2007 12:38:13 +0200 (CEST) [EMAIL PROTECTED] (Marco van de Voort) wrote: [EMAIL PROTECTED] (Marco van de Voort) wrote: A cast is really a cast. IOW the cast pchar(ansistring) is mostly a no-op. Traditional C code then usually treats the #0 as end of string. PChar(AnsiString) was a no-op typecast in the past and is nowadays a function. It checks whether the AnsiString is nil and if yes returns a pointer to a string containing one character: #0. That means: Pointer(AnsiString) <> Pointer(PChar(AnsiString)) To get a no-op typecase you can use: MyPChar:=PChar(Pointer(AnsiString)); Is this delphi compat, and if yes, what is this exactly for? I don't know. The change broke some lazarus code and now it is polluted by the ugly double type casts, just to get some no-op type casts. Because this fact is not widely known or often forgotten, many use the PChar() as simple type cast. That's why the lcl interfaces already got into troubles several times, so everytime we get strange errors I first search for these typecasts. Maybe we should mention this fact at a more prominent place in the wiki and docs. Maybe also add another "type" to get the OldTypecase behaviour. I allways thought that casting through Pointer() did return the real allocated data (thus including reference and length) Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
