On 21/06/15 17:46, Marco van de Voort wrote:
In our previous episode, patspiper said:
INPUT(
-l c
)
I think that should be -lc, not -l c. I don't know where the extra
space is coming from in your case.
Exactly!
I have just posted a message with my findings. Which program produces
link.res?
Am 2015-06-21 um 16:25 schrieb leledumbo:
but the documentation says that it is always Longint.
Can someone please correct this as it causes a lot of confusion.
fpdoc parser understands and interprets compiler directives, so it can't
display something that's defined differently for each
On 21/06/15 11:28, patspiper wrote:
Using 'ppc386 -s program1.pp' instead, line 121 of link.res is '-l c' in
the section:
INPUT(
-l c
)
I think that should be -lc, not -l c. I don't know where the extra
space is coming from in your case.
Jonas
The situation is as follows:
- Platform: Windows
- file1.obj: 3rd omf object file (no source available) that can be used
by Delphi linker and calls kernel32.dll functions such as GetTickCount
and GetLastError.
- file1.coff: file1.obj converted to coff format using objconv.exe
On 21/06/15 14:58, Marco van de Voort wrote:
In our previous episode, patspiper said:
Compiling the following simple program (from fpc prog manual
http://www.freepascal.org/docs-html/prog/progsu46.html#x53-520001.2.46)
yields a linking syntax error:
Is this a bug?
Not of a general kind, since
patspiper wrote:
On 21/06/15 14:58, Marco van de Voort wrote:
In our previous episode, patspiper said:
Compiling the following simple program (from fpc prog manual
http://www.freepascal.org/docs-html/prog/progsu46.html#x53-520001.2.46)
yields a linking syntax error:
Is this a bug?
Not of a
On 21/06/15 16:40, Jonas Maebe wrote:
On 21/06/15 11:28, patspiper wrote:
Using 'ppc386 -s program1.pp' instead, line 121 of link.res is '-l c' in
the section:
INPUT(
-l c
)
I think that should be -lc, not -l c. I don't know where the extra
space is coming from in your case.
Exactly!
I have
but the documentation says that it is always Longint.
Can someone please correct this as it causes a lot of confusion.
fpdoc parser understands and interprets compiler directives, so it can't
display something that's defined differently for each platform. As you can
see, we have *nix units
The documenation in
http://www.freepascal.org/docs-html/rtl/system/sizeint.html
says:
---
SizeInt
Signed integer type which fits for sizes
Declaration
Source position: systemh.inc line 251
type SizeInt= LongInt
On 21/06/15 14:58, Marco van de Voort wrote:
In our previous episode, patspiper said:
Compiling the following simple program (from fpc prog manual
http://www.freepascal.org/docs-html/prog/progsu46.html#x53-520001.2.46)
yields a linking syntax error:
Is this a bug?
Not of a general kind, since
On 21/06/15 15:50, patspiper wrote:
So the issue is fpc producing link.res with a -l c instead of -lc. Which
program specifically produces link.res?
It's the compiler. But this can't be a problem that always occurs,
because otherwise make all would fail too as fpmake by default also
links to
In our previous episode, patspiper said:
Compiling the following simple program (from fpc prog manual
http://www.freepascal.org/docs-html/prog/progsu46.html#x53-520001.2.46)
yields a linking syntax error:
Is this a bug?
Not of a general kind, since it works on most Linux distros. E.g. it
In our previous episode, patspiper said:
INPUT(
-l c
)
I think that should be -lc, not -l c. I don't know where the extra
space is coming from in your case.
Exactly!
I have just posted a message with my findings. Which program produces
link.res?
Maybe the problem is the $linklib
On Mon, June 22, 2015 00:24, fredvs wrote:
.
.
So LD_PRELOAD and LD_LIBRARY_PATH are unix only ?
What about Windows, what should be the TProcess.Environment.Text ?
= not OK.
I'm not aware of an equivalentof LD_PRELOAD on Windows.
As far as LD_LIBRARY_PATH is concerned - as far as I know,
The following simple program which uses the $LINKLIB compiler directive
builds fine under Linux:
program Project1;
{$Linklib c}
Const P : PChar = 'This is fun !';
Function strlen (P: PChar): Longint; cdecl; external;
begin
WriteLn ('Length of (',p,') : ',strlen(p))
end.
However,
On 21/06/15 21:43, patspiper wrote:
program Project1;
{$Linklib kernel32}
Function GetTickCount: DWORD; external;
begin
WriteLn ('GetTickCount ', GetTickCount);
end.
project1.lpr(10,1) Error: Undefined symbol:
P$PROJECT1_$$_GETTICKCOUNT$$LONGWORD
Changing the GetTickCount
On 21/06/15 22:20, patspiper wrote:
On 21/06/15 23:08, Jonas Maebe wrote:
On 21/06/15 21:43, patspiper wrote:
Changing the GetTickCount declaration to any of the following works:
Function GetTickCount: DWORD; external name
'_$dll$kernel32$GetTickCount';
Function GetTickCount: DWORD;
On 21/06/15 23:58, Jonas Maebe wrote:
On 21/06/15 22:20, patspiper wrote:
So what should be done to remedy the Windows case when $LINKLIB is used,
that is unless $LINKLIB is not to be used with Windows?
{$linklib xxx} can be useful on Windows if you have a DLL that has an
initialisation
@ Thomas = tanks for answer.
Unix uses a colon as path delimiter, not semicolon. I don't know about
LD_PRELOAD, but it should work at least for LD_LIBRARY_PATH.
Ha, ok... (by the way, what character is colon ?)
So LD_PRELOAD and LD_LIBRARY_PATH are unix only ?
What about Windows, what should
On Sun, June 21, 2015 22:58, Jonas Maebe wrote:
On 21/06/15 22:20, patspiper wrote:
On 21/06/15 23:08, Jonas Maebe wrote:
On 21/06/15 21:43, patspiper wrote:
Changing the GetTickCount declaration to any of the following works:
Function GetTickCount: DWORD; external name
On 21/06/15 23:08, Jonas Maebe wrote:
On 21/06/15 21:43, patspiper wrote:
program Project1;
{$Linklib kernel32}
Function GetTickCount: DWORD; external;
begin
WriteLn ('GetTickCount ', GetTickCount);
end.
project1.lpr(10,1) Error: Undefined symbol:
P$PROJECT1_$$_GETTICKCOUNT$$LONGWORD
Then something is wrong with how the documentation is generated
(shouldn't it be written by a human?).
In these automatic documentation generator days? I don't think so.
A documenation of a type that has different meanings on different
platforms should tell about this.
That's what a
Hello.
If a TProcess runs a executable who needs a library, that does the trick =
TProcess.Environment.Text := 'LD_PRELOAD='/the/directory/of/thelibrary.so'
;
You may also use this = (it seems bad ;-( =
http://xahlee.info/UnixResource_dir/_/ldpath.html ) =
TProcess.Environment.Text :=
On Sun, June 21, 2015 22:55, fredvs wrote:
Hello.
If a TProcess runs a executable who needs a library, that does the trick
=
TProcess.Environment.Text := 'LD_PRELOAD='/the/directory/of/thelibrary.so'
;
You may also use this = (it seems bad ;-( =
Ha, ok... (by the way, what character is colon ?)
= https://en.wikipedia.org/wiki/Colon_%28punctuation%29
= OK.
But =
So LD_PRELOAD and LD_LIBRARY_PATH are unix only ?
What about Windows, what should be the TProcess.Environment.Text ?
= not OK.
Thanks.
Fre;D
-
Many thanks ;-)
--
Hi,
Compiling the following simple program (from fpc prog manual
http://www.freepascal.org/docs-html/prog/progsu46.html#x53-520001.2.46)
yields a linking syntax error:
program Project1;
{$Linklib c}
Const P : PChar = 'This is fun !';
Function strlen (P: PChar): Longint; cdecl; external;
26 matches
Mail list logo
