[fpc-pascal] Makefile.fpc issues
Hi, Below is my current Makefile.fpc. I can generate the Makefile and do a make and make install ..., but a few things are not working 100%. Could anybody spare some time to help me sort out these minor issues. Issue #1 make; make install INSTALL_PREFIX=/opt/fpc make: Circular units - fpc_units dependency dropped. /bin/mkdir -p units /mnt/data/opt/fpc_2.0.x/bin/ppc386 -S2h . What is the cause of the Circular units message? Is it critical? Is it a issue in the Makefile or in my code? The code compiles fine though, so I guess it is something in the Makefile.fpc Issue #2 All compiled units are created in a single src/units directory, even for the linux/ and win32/ sub directories. Is this a good idea? Issue #3 make install INSTALL_PREFIX=/opt/fpc This installs the compiled units into the same FPC directory structure as the rest of the packages included with Free Pascal. After the make install... the units are installed in a sub directory called fpgfx, but for some reason the gfxbase.ppu and gfxbase.o files are not copied to that directory. All the other units are! I always have to copy it in manually. I get the same thing with my other package (fpGUI), the starting unit is not copied to the install directory. Makefile.fpc --- # # Makefile.fpc for fpGFX # [package] name=fpgfx version=0.2 [require] packages=fcl [target] units=gfxbase geldirty gelimage rsts=gfxbase dirs_linux=linux dirs_freebsd=linux dirs_netbsd=linux dirs_win32=win32 [compiler] sourcedir=emulayer unittargetdir=units options=-S2h [install] buildunit=gfxbase fpcpackage=y [default] fpcdir=/opt/fpc/src [rules] fpgfx$(PPUEXT): $(wildcard *.pp *.inc) [libs] libname=libfpgfx.so libversion=0.2 --- END -- Source directory layout src/ emulayer/ geldirty.pp gelimage.pp linux/ gfximpl.pp gfx_x11.pp win32/ gfximpl.pp gfx_gdi.pp units/ gfxbase.pp keys.inc Makefile Makefile.fpc Thanks for you time... Kind regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Ansi strings
Here is 2 examples of how the fpc compiler dos when comparing a string constant with a pchar . The first is compiled with the 204 compiler and second one is compiled with the 202 compiler. I am using the compiler on an embedded Arm 7 platform and Ansi strings is not an option. I want to force the 204 compiler to use short strings but the only option I can se, that have anything to do with strings is the (-Sh use ansistrings) and that is just the opposite of what I want. Any hints? Carsten --- 204 - .stabn 68,0,198,.Ll126 - Beas_Do_Text_Write # [198] if FileName=BeasTyp.COM1name then ldr r0,.L672 ldr r4,[r0] sub r0,r11,#120 bl FPC_ANSISTR_DECR_REF ldr r0,[r11, #-44] bl fpc_pchar_to_ansistr str r0,[r11, #-120] ldr r0,[r11, #-120] mov r1,r4 bl fpc_ansistr_compare cmp r0,#0 beq .L665 b .L666 -- 202 - .stabn 68,0,198,.Ll124 - Beas_Do_Text_Write # [198] if FileName=BeasTyp.COM1name then ldr r4,.L615 ldr r1,[r11, #-44] sub r0,r11,#312 bl fpc_pchar_to_shortstr sub r0,r11,#312 mov r1,r4 bl fpc_shortstr_compare cmp r0,#0 beq .L610 b .L611 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Merssage [Error](1,1): Unexpected end of file
I'm reading a file generated by another application, but it very often trigger '[Error](1,1): Unexpected end of file'. I just can't put my finger on the problem. I'm using Reset() and Readln(). It looks like it is not impacted by the read/write time to OS. I can't explain. My algo for reading is: while not eof(f) readln(f,s) process... end; Maybe when it read the last line it does not trigger properly the eof? I'll test loading a file with a string list to see if it causes the same error. (PS: I sent this message yesterday but I think it did not reach the list... I added 'Message' in the subject because the mailling list tought it was a command to execute!?!) -- Alexandre Leclerc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] AsciiZ confusion
Hi,
Sorry this is a long message, but hard to explain. I have a DLL I wrote in
FreePascal 2.0.2, which is communicating between a Delphi program and a
PowerBasic Dll, like follows...
PBdll exports PBSub ByRef as AsciiZMyFreePascall_DLL
DelphiDLLstubByRef_Variants
As noted, the Delphi Program integrates a DLL stub which forces me to make
calls using it's pre-defined Variants Only format.
The problem comes when I pass data into FPC via parameters byRef through a
procedure, into the PowerBasic DLL. The first parameter returns unmodified
and the second parameter returns only one character wide, as if FPC is
trying to receive back a pointer only, to the string space where the PB data
resides. Or possibly it's just garbage and looks this way.
The FPC DLL is setup as follows:
{$LONGSTRINGS ON}
library DelphiXchg;
uses Variants, strings;
//Declare PowerBasic external (a sub or function call, made no difference)
procedure subXchngAsciiZ(Data1, DATA2:string)stdcall;external 'PB.DLL';
//Declare the Delphi calling stub DLL (variants only);
function Delphstub(var vD1,vD2:variant):variant;stdcall;export;
//at runtime, Delphi sends in... vD1:='test'; vD2:=' '; // (vD2 is
place-held with a 'space')
begin
if vD1 = 'test'// vD1 is being sent
from Delphi
then subXchngAsciiZ(vD1, vD2); // call out to PB DLL
// vD1 should
come back 'tested'
// vD2 should
come back 'good'
end;
exports
Delphstub;// FPC Return value unused
begin
end.
==
When the Delphi calling program sends in the variant vD1:='test', (through
FPC to the PB DLL), FPC only gets back 'test' unmodified and variant vD2 is
coming back as 'g', (only the first character, instead of 'good', (ahhh but
vD2 did get modified at least)).
I thought that zero or null terminated AsciiZ data would handle the string
array length automatically in FPC, on 255 wide, but now I'm supposing I
may have to break the variants out, use explicit calls internally by typed
pointer reference and then reload the outgoing variants with the result data
from the pointers to the explicit variables before returning, but I've had
no success in figuring out how to set that up correctly.
Should it really be that much handling to pass AsciiZ on Variant types as
parameters, or am I overlooking something stupid simple? The only example I
have to go by is a VB program that makes calls directly across to PB, using
ByRef ASCIIZ, so the problem seems mostly from being forced to use the
Variant types in parameters from the Delphi calling program.
Thanks for any ideas.
AFP
---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 0635-3, 08/31/2006
Tested on: 8/31/2006 1:49:00 PM
avast! - copyright (c) 1988-2006 ALWIL Software.
http://www.avast.com
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Fw: [fpc-pascal] AsciiZ confusion
Let me remove some comments(sorry)
Hi,
Sorry this is a long message, but hard to explain. I have a DLL I wrote
in FreePascal 2.0.2, which is communicating between a Delphi program and a
PowerBasic Dll, like follows...
PBdll exports PBSub ByRef as AsciiZMyFreePascall_DLL
DelphiDLLstubByRef_Variants
As noted, the Delphi Program integrates a DLL stub which forces me to make
calls using it's pre-defined Variants Only format.
The problem comes when I pass data into FPC via parameters byRef through
a procedure, into the PowerBasic DLL. The first parameter returns
unmodified and the second parameter returns only one character wide, as if
FPC is trying to receive back a pointer only, to the string space where
the PB data resides. Or possibly it's just garbage and looks this way.
The FPC DLL is setup as follows:
{$LONGSTRINGS ON}
library DelphiXchg;
uses Variants, strings;
//Declare PowerBasic external
procedure subXchngAsciiZ(Data1, DATA2:string)stdcall;external 'PB.DLL';
//Declare the Delphi calling stub (variants only);
function Delphstub(var vD1,vD2:variant):variant;stdcall;export;
begin
if vD1 = 'test' then subXchngAsciiZ(vD1, vD2);
exports
Delphstub;//unused
begin
end.
==
When the Delphi calling program sends in the variant vD1:='test', (through
FPC to the PB DLL), FPC only gets back 'test' unmodified and variant vD2
is coming back as 'g', (only the first character, instead of 'good', (ahhh
but vD2 did get modified at least)).
I thought that zero or null terminated AsciiZ data would handle the string
array length automatically in FPC, on 255 wide, but now I'm supposing I
may have to break the variants out, use explicit calls internally by typed
pointer reference and then reload the outgoing variants with the result
data from the pointers to the explicit variables before returning, but
I've had no success in figuring out how to set that up correctly.
Should it really be that much handling to pass AsciiZ on Variant types as
parameters, or am I overlooking something stupid simple? The only example
I have to go by is a VB program that makes calls directly across to PB,
using ByRef ASCIIZ, so the problem seems mostly from being forced to use
the Variant types in parameters from the Delphi calling program.
Thanks for any ideas.
AFP
---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 0635-3, 08/31/2006
Tested on: 8/31/2006 1:49:00 PM
avast! - copyright (c) 1988-2006 ALWIL Software.
http://www.avast.com
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
---
avast! Antivirus: Inbound message clean.
Virus Database (VPS): 0635-3, 08/31/2006
Tested on: 8/31/2006 1:52:02 PM
avast! - copyright (c) 1988-2006 ALWIL Software.
http://www.avast.com
---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 0635-3, 08/31/2006
Tested on: 8/31/2006 2:01:58 PM
avast! - copyright (c) 1988-2006 ALWIL Software.
http://www.avast.com
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] AsciiZ confusion
As noted, the Delphi Program integrates a DLL stub which forces me to make calls using it's pre-defined Variants Only format. I'm not clear why you need to have a FPC DLL between a PB DLL and Delphi... this part makes no sense. If you need to, dynamically load the DLL. If you are exporting params compatible with FPC, they should also be compatible with Delphi. M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Merssage [Error](1,1): Unexpected end of file
There was no problems with ReadLn... after 2 hours of debugging I put my finger on the problem; somewhere else in the software. Sorry for that. Regards. -- Alexandre Leclerc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] AsciiZ confusion
- Original Message - From: Matt Emson [EMAIL PROTECTED] To: afpTeam [EMAIL PROTECTED]; FPC-Pascal users discussions fpc-pascal@lists.freepascal.org Sent: Thursday, August 31, 2006 2:57 PM Subject: Re: [fpc-pascal] AsciiZ confusion As noted, the Delphi Program integrates a DLL stub which forces me to make calls using it's pre-defined Variants Only format. I'm not clear why you need to have a FPC DLL between a PB DLL and Delphi... this part makes no sense. If you need to, dynamically load the DLL. If you are exporting params compatible with FPC, they should also be compatible with Delphi. M The Delphi program is a canned application which makes provision for a stub DLL, such as I wrote. I have no access to the Delphi app's core functionality. The PB DLL is an externalized DLL as only part of the PB program. Therefore, the only way I know to share data between the two, is to talk to the Stub DLL from a scripting engine within the Delphi program. The Delphi App's authors create the calling conventions, i.e. all varients from within the Delphi program, so again, I'm forced to use them. The real question I guess, is whether I should be able to pass AsciiZ directly through the DLL as I indicated, given the Varients are first set to ascii strings, then asciiZ, then back to ascii strings as they return back into Delphi, or will this level of type changing confuse FPC at runtime? AFP --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0635-3, 08/31/2006 Tested on: 8/31/2006 6:14:41 PM avast! - copyright (c) 1988-2006 ALWIL Software. http://www.avast.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
