Discussion:
[fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows
LacaK
2017-03-14 12:30:17 UTC
Permalink
Hi,

I have C/C++ librarby (".lib" for Windows and ".a" for Linux) from Intel
IPP package (they distribute ".lib" and also ".dll" for Windows and ".a"
for Linux)

Can I link in FPC (on Windows) at compile time to this ".lib" versions ?
Or only possible way is link at runtime using ".dll" (and distribute
DLLs with my EXE)?
(I guess, that FPC can not link to libraries not created in FPC itself.
So format of supplied ".lib" is not compatible with what FPC expects)

I am trying do something like:
{$linklib libippi}
function ippiThreshold_LTValGTVal_8u_C1IR(pSrcDst: PIpp8u; srcDstStep: int;
roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u;
thresholdGT: Ipp8u;
valueGT: Ipp8u): IppStatus; external; // 'ippi.dll';

(In Project Options I have path to libippi.a in -Fl)

But I get error: test_IPP.lpr(24,1) Error: Undefined symbol:
IPP_IPPITHRESHOLD_LTVALGTVAL_8U_C1IR$PIPP8U$LONGINT$IPPISIZE$BYTE$BYTE$BYTE$BYTE$$IPPSTATUS

I am doing something wrong or just this is not possible ?

Thank you
-Laco.
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://li
Sven Barth via fpc-devel
2017-03-14 13:33:07 UTC
Permalink
Post by LacaK
Hi,
I have C/C++ librarby (".lib" for Windows and ".a" for Linux) from Intel
IPP package (they distribute ".lib" and also ".dll" for Windows and ".a"
for Linux)
Post by LacaK
Can I link in FPC (on Windows) at compile time to this ".lib" versions ?
Or only possible way is link at runtime using ".dll" (and distribute DLLs
with my EXE)?
Post by LacaK
(I guess, that FPC can not link to libraries not created in FPC itself.
So format of supplied ".lib" is not compatible with what FPC expects)
Post by LacaK
{$linklib libippi}
function ippiThreshold_LTValGTVal_8u_C1IR(pSrcDst: PIpp8u; srcDstStep: int;
roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u;
thresholdGT: Ipp8u;
Post by LacaK
valueGT: Ipp8u): IppStatus; external; // 'ippi.dll';
(In Project Options I have path to libippi.a in -Fl)
IPP_IPPITHRESHOLD_LTVALGTVAL_8U_C1IR$PIPP8U$LONGINT$IPPISIZE$BYTE$BYTE$BYTE$BYTE$$IPPSTATUS
Post by LacaK
I am doing something wrong or just this is not possible ?
You might want to try the external linker using -Xe. The internal linker
does not yet support COFF import libraries.

Regards,
Sven
Sven Barth via fpc-devel
2017-03-14 13:36:23 UTC
Permalink
Post by Sven Barth via fpc-devel
Post by LacaK
Hi,
I have C/C++ librarby (".lib" for Windows and ".a" for Linux) from
Intel IPP package (they distribute ".lib" and also ".dll" for Windows and
".a" for Linux)
Post by Sven Barth via fpc-devel
Post by LacaK
Can I link in FPC (on Windows) at compile time to this ".lib" versions
? Or only possible way is link at runtime using ".dll" (and distribute DLLs
with my EXE)?
Post by Sven Barth via fpc-devel
Post by LacaK
(I guess, that FPC can not link to libraries not created in FPC itself.
So format of supplied ".lib" is not compatible with what FPC expects)
Post by Sven Barth via fpc-devel
Post by LacaK
{$linklib libippi}
function ippiThreshold_LTValGTVal_8u_C1IR(pSrcDst: PIpp8u; srcDstStep: int;
roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u;
thresholdGT: Ipp8u;
Post by Sven Barth via fpc-devel
Post by LacaK
valueGT: Ipp8u): IppStatus; external; // 'ippi.dll';
(In Project Options I have path to libippi.a in -Fl)
IPP_IPPITHRESHOLD_LTVALGTVAL_8U_C1IR$PIPP8U$LONGINT$IPPISIZE$BYTE$BYTE$BYTE$BYTE$$IPPSTATUS
Post by Sven Barth via fpc-devel
Post by LacaK
I am doing something wrong or just this is not possible ?
You might want to try the external linker using -Xe. The internal linker
does not yet support COFF import libraries.

Small correction: I meant "static COFF libraries", not "COFF import
libraries" (the later can be considered a special case of the former
though).

Regards,
Sven
Tomas Hajny
2017-03-14 13:51:09 UTC
Permalink
Post by Sven Barth via fpc-devel
Post by LacaK
Post by LacaK
Hi,
I have C/C++ librarby (".lib" for Windows and ".a" for Linux) from
Intel IPP package (they distribute ".lib" and also ".dll" for Windows and
".a" for Linux)
Post by LacaK
Post by LacaK
Can I link in FPC (on Windows) at compile time to this ".lib" versions
? Or only possible way is link at runtime using ".dll" (and distribute DLLs
with my EXE)?
Post by LacaK
Post by LacaK
(I guess, that FPC can not link to libraries not created in FPC
itself.
So format of supplied ".lib" is not compatible with what FPC expects)
Post by LacaK
Post by LacaK
{$linklib libippi}
int;
Post by LacaK
Post by LacaK
roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u;
thresholdGT: Ipp8u;
Post by LacaK
Post by LacaK
valueGT: Ipp8u): IppStatus; external; // 'ippi.dll';
(In Project Options I have path to libippi.a in -Fl)
IPP_IPPITHRESHOLD_LTVALGTVAL_8U_C1IR$PIPP8U$LONGINT$IPPISIZE$BYTE$BYTE$BYTE$BYTE$$IPPSTATUS
Post by LacaK
Post by LacaK
I am doing something wrong or just this is not possible ?
.
.

Doesn't the declaration above miss "cdecl;" or something similar (before
"external")? You could also use the 'name' modifier, I guess, to avoid FPC
symbol mangling (but cdecl should do it as well).

Apart from that - based on the name, I'd suspect that it's C++ rather than
C (linking to C++ isn't fully supported by FPC yet as far as I know)?

Tomas


_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc
silvioprog
2017-03-14 14:29:06 UTC
Permalink
On Tue, Mar 14, 2017 at 10:36 AM, Sven Barth via fpc-devel <
fpc-***@lists.freepascal.org> wrote:
[...]
Post by Sven Barth via fpc-devel
Small correction: I meant "static COFF libraries", not "COFF import
libraries" (the later can be considered a special case of the former
though).
Is there any plan to support COFF object on Windows? I've used it fine on
Linux ({$l blah.a}), but on Windows it breaks the compilation with "illegal
coff magic while reading blah".

--
Silvio Clécio
silvioprog
2017-03-14 15:04:24 UTC
Permalink
Post by silvioprog
On Tue, Mar 14, 2017 at 10:36 AM, Sven Barth via fpc-devel <
[...]
Post by Sven Barth via fpc-devel
Small correction: I meant "static COFF libraries", not "COFF import
libraries" (the later can be considered a special case of the former
though).
Is there any plan to support COFF object on Windows? I've used it fine on
Linux ({$l blah.a}), but on Windows it breaks the compilation with "illegal
coff magic while reading blah".
Please ignore my question. :-D

I have fpc 3 and trunk in same machine, now after testing in trunk version
it work like a charm. ^^'
--
Silvio Clécio
Pierre Free Pascal
2017-03-14 13:58:36 UTC
Permalink
-----Message d'origine-----
part de LacaK
Envoyé : mardi 14 mars 2017 13:30
Objet : [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal
on Windows
Hi,
I have C/C++ librarby (".lib" for Windows and ".a" for Linux) from Intel
IPP package (they distribute ".lib" and also ".dll" for Windows and ".a"
for Linux)
Can I link in FPC (on Windows) at compile time to this ".lib" versions ?
Or only possible way is link at runtime using ".dll" (and distribute
DLLs with my EXE)?
(I guess, that FPC can not link to libraries not created in FPC itself.
So format of supplied ".lib" is not compatible with what FPC expects)
{$linklib libippi}
function ippiThreshold_LTValGTVal_8u_C1IR(pSrcDst: PIpp8u; srcDstStep: int;
roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u;
thresholdGT: Ipp8u;
valueGT: Ipp8u): IppStatus; external; // 'ippi.dll';
Did you try this:
function ippiThreshold(pSrcDst: PIpp8u; srcDstStep: int;
roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u; thresholdGT: Ipp8u;
valueGT: Ipp8u): IppStatus; external 'ippi.dll' name 'ippiThreshold_LTValGTVal_8u_C1IR';
You should use
objdump -p ippi.dll
to get the names of the exported procedures/functions.

You could also test cppdecl; modifier for linux target,

In the hope it will help,

Pierre Muller
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/
Ladislav Karrach
2017-03-14 14:47:49 UTC
Permalink
Post by Pierre Free Pascal
function ippiThreshold(pSrcDst: PIpp8u; srcDstStep: int;
roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u; thresholdGT: Ipp8u;
valueGT: Ipp8u): IppStatus; external 'ippi.dll' name 'ippiThreshold_LTValGTVal_8u_C1IR';
You should use
objdump -p ippi.dll
to get the names of the exported procedures/functions.
Yes I know, this work: external 'ippi.dll' (I have added also "stdcall")
But my question was regarding how to staticaly link provided libraries
into my EXE (so I do not want distribute also all DLLs)
Just like one can do it in C/C++

-Laco

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi
Yury Sidorov
2017-03-15 11:54:17 UTC
Permalink
Post by Ladislav Karrach
Post by Pierre Free Pascal
function ippiThreshold(pSrcDst: PIpp8u; srcDstStep: int;
roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u; thresholdGT: Ipp8u;
valueGT: Ipp8u): IppStatus; external 'ippi.dll' name
'ippiThreshold_LTValGTVal_8u_C1IR';
You should use
objdump -p ippi.dll
to get the names of the exported procedures/functions.
Yes I know, this work: external 'ippi.dll' (I have added also "stdcall")
But my question was regarding how to staticaly link provided libraries
into my EXE (so I do not want distribute also all DLLs)
Just like one can do it in C/C++
Yes, you can statically link a COFF library created by other compiler.

Use objdump as explained earlier to find out the name of ippiThreshold
function in the static library. It may be prefixed with "_".

Then insert the proper name in the external declaration:

function ippiThreshold(pSrcDst: PIpp8u; srcDstStep: int; roiSize:
IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u; thresholdGT: Ipp8u;
valueGT: Ipp8u): IppStatus; external name '<proper_name>';

Also specify proper calling convention: cdecl or stdcall. But it does
not affect linking if name is explicitly specified.

Yury.
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lis
LacaK
2017-03-15 12:56:19 UTC
Permalink
Post by Yury Sidorov
Post by Ladislav Karrach
Post by Pierre Free Pascal
function ippiThreshold(pSrcDst: PIpp8u; srcDstStep: int;
roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u; thresholdGT: Ipp8u;
valueGT: Ipp8u): IppStatus; external 'ippi.dll' name
'ippiThreshold_LTValGTVal_8u_C1IR';
You should use
objdump -p ippi.dll
to get the names of the exported procedures/functions.
Yes I know, this work: external 'ippi.dll' (I have added also "stdcall")
But my question was regarding how to staticaly link provided libraries
into my EXE (so I do not want distribute also all DLLs)
Just like one can do it in C/C++
Yes, you can statically link a COFF library created by other compiler.
Use objdump as explained earlier to find out the name of ippiThreshold
function in the static library. It may be prefixed with "_".
But does it works also on Windows ? (as far as I does not have "objdump"
utility there?)
L.

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fp
Sven Barth via fpc-devel
2017-03-15 13:35:34 UTC
Permalink
Post by LacaK
Post by Yury Sidorov
Post by Ladislav Karrach
Post by Pierre Free Pascal
function ippiThreshold(pSrcDst: PIpp8u; srcDstStep: int;
roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u; thresholdGT: Ipp8u;
valueGT: Ipp8u): IppStatus; external 'ippi.dll' name
'ippiThreshold_LTValGTVal_8u_C1IR';
You should use
objdump -p ippi.dll
to get the names of the exported procedures/functions.
Yes I know, this work: external 'ippi.dll' (I have added also "stdcall")
But my question was regarding how to staticaly link provided libraries
into my EXE (so I do not want distribute also all DLLs)
Just like one can do it in C/C++
Yes, you can statically link a COFF library created by other compiler.
Use objdump as explained earlier to find out the name of ippiThreshold
function in the static library. It may be prefixed with "_".
Post by LacaK
But does it works also on Windows ? (as far as I does not have "objdump"
utility there?)
Post by LacaK
L.
objdump is distributed as part of a FPC or Lazarus release.

Regards,
Sven
LacaK
2017-03-15 16:06:29 UTC
Permalink
Post by LacaK
Post by Yury Sidorov
Yes, you can statically link a COFF library created by other compiler.
Use objdump as explained earlier to find out the name of
ippiThreshold function in the static library. It may be prefixed with "_".
Post by LacaK
But does it works also on Windows ? (as far as I does not have
"objdump" utility there?)
Post by LacaK
L.
objdump is distributed as part of a FPC or Lazarus release.
Thank you!

Now I can use "objdump -t ippcore.lib" and I get something like this:

ippcore.dll: file format pei-i386

SYMBOL TABLE:
[ 0](sec 0)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .idata$4
[ 1](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .idata$5
[ 2](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .idata$6
[ 3](sec 3)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .text
[ 4](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 ***@4
[ 5](sec 3)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 ***@4
[ 6](sec 0)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000
__IMPORT_DESCRIPTOR_ippcore


When I use "objdump -t libippcore.a" I get:
In archive libippcore.a:
objdump: pcorever.o: File format not recognized
objdump: owninit.o: File format not recognized
objdump: ownfinitenans.o: File format not recognized
objdump: owncpufeatures.o: File format not recognized
objdump: owncpudefs.o: File format not recognized
objdump: ippstatus.o: File format not recognized
objdump: ippompinit.o: File format not recognized
objdump: ippnanfp.o: File format not recognized
objdump: ippmalloc64x.o: File format not recognized
objdump: ippmalloc.o: File format not recognized
objdump: ippl2cache.o: File format not recognized
objdump: ippinit.o: File format not recognized
objdump: ippftzdaz.o: File format not recognized
objdump: ippcpufreq.o: File format not recognized
objdump: ippcpufeatures.o: File format not recognized
objdump: ippcpu.o: File format not recognized
objdump: ippcachesize.o: File format not recognized
objdump: ippalignptr.o: File format not recognized
objdump: safeinit32eas.o: File format not recognized
objdump: pscpuinfo32eas.o: File format not recognized
objdump: pscpudef32eas.o: File format not recognized
objdump: ps_destroy_ssx_32e.o: File format not recognized
objdump: intel_f2int.o: File format not recognized

But this can be because probably "libippcore.a" is for Linux 64 ...

L.
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/
Yury Sidorov
2017-03-15 17:09:16 UTC
Permalink
Post by LacaK
Post by Sven Barth via fpc-devel
Post by Yury Sidorov
Yes, you can statically link a COFF library created by other compiler.
Use objdump as explained earlier to find out the name of ippiThreshold function in the static library. It may be prefixed with
"_".
But does it works also on Windows ? (as far as I does not have "objdump" utility there?)
L.
objdump is distributed as part of a FPC or Lazarus release.
Thank you!
ippcore.dll: file format pei-i386
[ 0](sec 0)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .idata$4
ippcore.lib is just an import library for ippcore.dll. You should not
use it for static linking.
According to the Intel's site you should use the following libs for
static linking:
ippimt.lib ippsmt.lib ippcorelmt.lib

Yury.
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi
LacaK
2017-03-16 08:11:50 UTC
Permalink
Post by Yury Sidorov
ippcore.lib is just an import library for ippcore.dll. You should not
use it for static linking.
According to the Intel's site you should use the following libs for
ippimt.lib ippsmt.lib ippcorelmt.lib
Thank you!

Now I do:
{$linklib ippcoremt.lib}
function ippGetLibVersion: PIppLibraryVersion; extdecl; external name
'_ippGetLibVersion';
But I get error:
ipp.pas(467,0) Error: Invalid DLL .\Intel_IPP\ippcoremt.lib, Dos
Header invalid

objdump for "ippcoremt.lib" shows that format is: pe-i386

When I try another:
{$link .\Intel_IPP\ippcoremt.lib}
function ippGetLibVersion: PIppLibraryVersion; extdecl; external name
'_ippGetLibVersion';
Then I get another error:
test_IPP.lpr(24,1) Error: Illegal COFF Magic while reading
.\Intel_IPP\ippcoremt.lib

Am I doing something wrong, or there is some kind of incompatibility
between format of supplied libraries and object files supported by FPC ?
(I am on FPC 2.6.4 , is there chance when I will use 3.0.2 that
something changes in this?)

-Laco.

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman
Karoly Balogh (Charlie/SGR)
2017-03-16 09:03:40 UTC
Permalink
Hi,
Post by LacaK
test_IPP.lpr(24,1) Error: Illegal COFF Magic while reading
.\Intel_IPP\ippcoremt.lib
Am I doing something wrong, or there is some kind of incompatibility
between format of supplied libraries and object files supported by FPC ?
(I am on FPC 2.6.4 , is there chance when I will use 3.0.2 that
something changes in this?)
Someone wrote already, that the internal linker doesn't support static
libraries. You have to use -Xe (GNU LD, as external linker) to have a
fighting chance for this to work. It's bundled with FPC. Again, I'm not
saying it will work with GNU LD, I'm saying it won't work with the
internal linker, and that's true for any FPC version currently.

Charlie
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo
LacaK
2017-03-16 10:01:04 UTC
Permalink
Post by Karoly Balogh (Charlie/SGR)
Hi,
Post by LacaK
test_IPP.lpr(24,1) Error: Illegal COFF Magic while reading
.\Intel_IPP\ippcoremt.lib
Am I doing something wrong, or there is some kind of incompatibility
between format of supplied libraries and object files supported by FPC ?
(I am on FPC 2.6.4 , is there chance when I will use 3.0.2 that
something changes in this?)
Someone wrote already, that the internal linker doesn't support static
libraries. You have to use -Xe (GNU LD, as external linker) to have a
fighting chance for this to work. It's bundled with FPC. Again, I'm not
saying it will work with GNU LD, I'm saying it won't work with the
internal linker, and that's true for any FPC version currently.
Thank you. Now I have this FPC command line (added -Xe):

D:\Programy\Lazarus\fpc\2.6.4\bin\i386-win32\fpc.exe -B -MObjFPC -Scghi
-O1 -g -gl -XX -l -vewnhibq -FiD:\TEMP\zmazma\lib\i386-win32
-FlD:\TEMP\zmazma\Intel_IPP -FuD:\TEMP\zmazma\
-FUD:\TEMP\zmazma\lib\i386-win32\ -Xe test_IPP.lpr

But I still get :
Error: Invalid DLL .\Intel_IPP\ippcoremt.lib, Dos Header invalid

When I have removed from source code {$linklib} and use this command line:
(added: -k--library -k:ippcoremt.lib -k--library-path
-kD:\TEMP\zmazma\Intel_IPP)

D:\Programy\Lazarus\fpc\2.6.4\bin\i386-win32\fpc.exe -B -MObjFPC -Scghi
-O1 -g -gl -k--library -k:ippcoremt.lib -k--library-path
-kD:\TEMP\zmazma\Intel_IPP -vewnhibq -FiD:\TEMP\zmazma\lib\i386-win32
-FlD:\TEMP\zmazma\Intel_IPP -FuD:\TEMP\zmazma\
-FUD:\TEMP\zmazma\lib\i386-win32\ -Xe test_IPP.lpr

Then I get:
test_IPP.lpr(17,1) Error: undefined reference to `ippGetLibVersion'
(I have tried also: _ippGetLibVersion, ***@0 ...)

-Laco
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-deve
Yury Sidorov
2017-03-16 10:28:31 UTC
Permalink
Post by LacaK
test_IPP.lpr(17,1) Error: undefined reference to `ippGetLibVersion'
I've downloaded the IPP libs and did some tests to make sure that static
linking is possible.

The working declaration is:

{$L ippcoremt.lib}
function ippGetLibVersion: PIppLibraryVersion; cdecl; external name
'***@0';

You need to use the external linker via the -Xe option, since internal
linker does not support static libraries. Only single object files can
be linked.

***@0 - is the C++ mangled name used by MS VC++. FPC
supports then "cppdecl" calling convention, but only for the GCC
compiler, which uses different name mangling algorithm. So you need to
use cdecl and manually specify the name. Function names can be found
using "objdump -t ippcoremt.lib". You should specify the name without
the "_" prefix. It is added automatically when cdecl is used.

Yury.
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailma
LacaK
2017-03-16 11:12:56 UTC
Permalink
Post by Yury Sidorov
Post by LacaK
test_IPP.lpr(17,1) Error: undefined reference to `ippGetLibVersion'
I've downloaded the IPP libs and did some tests to make sure that
static linking is possible.
Thank you very much for your effort!
You use cdecl, but in header files is stated stdcall for Windows, isn't
it problem ?

Besides that it does not work for me, when I add another two functions.
Attached my example.

I get error:
.\Intel_IPP\\ippcoremt.lib(C:/commander/production/ipp201702gold/windows_ia32/.build/windows/obj/ia32/core/s/st/owncpufeatures.obj):(.text[_ownGetMaskFeatures]+0x35):
undefined reference to `__security_cookie'

L.
Yury Sidorov
2017-03-16 11:42:30 UTC
Permalink
Post by LacaK
Post by Yury Sidorov
Post by LacaK
test_IPP.lpr(17,1) Error: undefined reference to `ippGetLibVersion'
I've downloaded the IPP libs and did some tests to make sure that
static linking is possible.
Thank you very much for your effort!
You use cdecl, but in header files is stated stdcall for Windows, isn't
it problem ?
You are right. The headers use stdcall. You need also use stdcall and
add "_" before names - use the same names as reported by objdump.

function ippGetLibVersion: PIppLibraryVersion; stdcall; external name
Post by LacaK
Besides that it does not work for me, when I add another two functions.
Attached my example.
undefined reference to `__security_cookie'
Looks like you need to include the bufferoverflow.lib

See here:
http://stackoverflow.com/questions/21627607/gcc-linker-error-undefined-reference-to-security-cookie

Yury.
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/list
LacaK
2017-03-16 12:37:21 UTC
Permalink
Post by Yury Sidorov
Post by LacaK
Besides that it does not work for me, when I add another two functions.
Attached my example.
undefined reference to `__security_cookie'
Looks like you need to include the bufferoverflow.lib
http://stackoverflow.com/questions/21627607/gcc-linker-error-undefined-reference-to-security-cookie
I do not have such library. Intel does not distribute it, there are
hints that it was part of old Microsoft SDK v5 ...
It becomes more complicated than I expected, so I abandon this way. I
will use dynamic linking ...
Thank you for your help
-Laco.

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/
Sven Barth via fpc-devel
2017-03-15 18:52:23 UTC
Permalink
Post by LacaK
But this can be because probably "libippcore.a" is for Linux 64 ...
Yes, the Windows one only supports PE, not ELF.

Regards,
Sven
silvioprog
2017-03-14 14:57:38 UTC
Permalink
Post by LacaK
Hi,
I have C/C++ librarby (".lib" for Windows and ".a" for Linux) from Intel
IPP package (they distribute ".lib" and also ".dll" for Windows and ".a"
for Linux)
Can I link in FPC (on Windows) at compile time to this ".lib" versions ?
Or only possible way is link at runtime using ".dll" (and distribute DLLs
with my EXE)?
(I guess, that FPC can not link to libraries not created in FPC itself. So
format of supplied ".lib" is not compatible with what FPC expects)
{$linklib libippi}
function ippiThreshold_LTValGTVal_8u_C1IR(pSrcDst: PIpp8u; srcDstStep: int;
Ipp8u;
valueGT: Ipp8u): IppStatus; external; // 'ippi.dll';
(In Project Options I have path to libippi.a in -Fl)
IPP_IPPITHRESHOLD_LTVALGTVAL_8U_C1IR$PIPP8U$LONGINT$IPPISIZE
$BYTE$BYTE$BYTE$BYTE$$IPPSTATUS
test 1: are you on win32? If so, did you try using prefix "_"? eg:

function _ippiThreshold_LTValGTVal_8u_C1IR(pSrcDst: PIpp8u; srcDstStep: int;
roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u; thresholdGT:
Ipp8u;
valueGT: Ipp8u): IppStatus; external;

test 2: put the library implementation below function declaration, eg:

function _ippiThreshold_LTValGTVal_8u_C1IR(pSrcDst: PIpp8u; srcDstStep: int;
roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u; thresholdGT:
Ipp8u;
valueGT: Ipp8u): IppStatus; external;
{$linklib libippi}

fix 1: check which convention your library was compiled, supposing it was
compiled supporting CDECL, you need to specify it on your Pascal binding,
avoiding low-level errors at runtime:

function _ippiThreshold_LTValGTVal_8u_C1IR(pSrcDst: PIpp8u; srcDstStep: int;
roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u; thresholdGT:
Ipp8u;
valueGT: Ipp8u): IppStatus; cdecl; external;

Anyway I've tried to use COFF objects on Windows, but I'm not sure if FPC
supports that because it returns a "illegal COFF magic while reading some
lib". :-/ (on Linux it works like a charm)
Post by LacaK
I am doing something wrong or just this is not possible ?
Thank you
-Laco.
--
Silvio Clécio
silvioprog
2017-03-14 15:03:12 UTC
Permalink
On Tue, Mar 14, 2017 at 11:57 AM, silvioprog <***@gmail.com> wrote:
[...]
Post by silvioprog
Anyway I've tried to use COFF objects on Windows, but I'm not sure if FPC
supports that because it returns a "illegal COFF magic while reading some
lib". :-/ (on Linux it works like a charm)
Oh, sorry. It works on Windows too. I've used the wrong compiler version,
because I have fpc 3 and trunk in same machine. ^^' I'm going to share the
steps I've done ...
--
Silvio Clécio
silvioprog
2017-03-14 15:26:46 UTC
Permalink
Post by silvioprog
[...]
Post by silvioprog
Anyway I've tried to use COFF objects on Windows, but I'm not sure if FPC
supports that because it returns a "illegal COFF magic while reading some
lib". :-/ (on Linux it works like a charm)
Oh, sorry. It works on Windows too. I've used the wrong compiler version,
because I have fpc 3 and trunk in same machine. ^^' I'm going to share the
steps I've done ...
Done. Very small test in attachment to you check if your FPC version
supports COFF objects.

The attached package has the file .a, it was built with:

$ gcc -c foo.c -o libfoo.o
$ ar rcs libfoo.a libfoo.o

Now, just open the list.lpr, it may compile and run properly. The test just
prints "bar" at console.
--
Silvio Clécio
LacaK
2017-03-14 15:26:25 UTC
Permalink
Post by LacaK
Hi,
I have C/C++ librarby (".lib" for Windows and ".a" for Linux) from
Intel IPP package (they distribute ".lib" and also ".dll" for
Windows and ".a" for Linux)
Can I link in FPC (on Windows) at compile time to this ".lib"
versions ? Or only possible way is link at runtime using ".dll"
(and distribute DLLs with my EXE)?
(I guess, that FPC can not link to libraries not created in FPC
itself. So format of supplied ".lib" is not compatible with what
FPC expects)
{$linklib libippi}
function ippiThreshold_LTValGTVal_8u_C1IR(pSrcDst: PIpp8u;
srcDstStep: int;
roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u;
thresholdGT: Ipp8u;
valueGT: Ipp8u): IppStatus; external; // 'ippi.dll';
(In Project Options I have path to libippi.a in -Fl)
IPP_IPPITHRESHOLD_LTVALGTVAL_8U_C1IR$PIPP8U$LONGINT$IPPISIZE$BYTE$BYTE$BYTE$BYTE$$IPPSTATUS
function _ippiThreshold_LTValGTVal_8u_C1IR(pSrcDst: PIpp8u;
srcDstStep: int;
roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u;
thresholdGT: Ipp8u;
valueGT: Ipp8u): IppStatus; external;
here I get (without {$linklib}):
Error: Undefined symbol:
IPP__IPPITHRESHOLD_LTVAL_8U_C1IR$PIPP8U$LONGINT$IPPISIZE$BYTE$BYTE$$IPPSTATUS
Post by LacaK
function _ippiThreshold_LTValGTVal_8u_C1IR(pSrcDst: PIpp8u;
srcDstStep: int;
roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u;
thresholdGT: Ipp8u;
valueGT: Ipp8u): IppStatus; external;
{$linklib libippi}
here I get:
Error: Undefined symbol:
IPP__IPPITHRESHOLD_LTVAL_8U_C1IR$PIPP8U$LONGINT$IPPISIZE$BYTE$BYTE$$IPPSTATUS
(same error if I add: {$linklib ippi} or {$linklib libippi} ... ippi.lib
and libippi.a are in directory where -Fl points)
Post by LacaK
fix 1: check which convention your library was compiled,
I think it is stdcall and I have this calling convention there (extdecl
is macro: {$DEFINE extdecl:=stdcall} ):
function _ippiThreshold_LTVal_8u_C1IR(pSrcDst: PIpp8u;srcDstStep:
int; roiSize: IppiSize; threshold: Ipp8u; value: Ipp8u): IppStatus;
extdecl; external;

-Laco.
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-
silvioprog
2017-03-14 15:39:18 UTC
Permalink
[...]
Error: Undefined symbol: IPP__IPPITHRESHOLD_LTVAL_8U_C1
IR$PIPP8U$LONGINT$IPPISIZE$BYTE$BYTE$$IPPSTATUS
Post by silvioprog
function _ippiThreshold_LTValGTVal_8u_C1IR(pSrcDst: PIpp8u; srcDstStep: int;
roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u;
thresholdGT: Ipp8u;
valueGT: Ipp8u): IppStatus; external;
{$linklib libippi}
Error: Undefined symbol: IPP__IPPITHRESHOLD_LTVAL_8U_C1
IR$PIPP8U$LONGINT$IPPISIZE$BYTE$BYTE$$IPPSTATUS
(same error if I add: {$linklib ippi} or {$linklib libippi} ... ippi.lib
and libippi.a are in directory where -Fl points)
Post by silvioprog
fix 1: check which convention your library was compiled,
I think it is stdcall and I have this calling convention there (extdecl is
function _ippiThreshold_LTVal_8u_C1IR(pSrcDst: PIpp8u;srcDstStep: int;
roiSize: IppiSize; threshold: Ipp8u; value: Ipp8u): IppStatus;
extdecl; external;
Awesome. Now we need to check how libippi had exported its symbols. :-) For
example, to check the symbols from the libfoo.a sent in my previous message:

$ objdump -t libfoo.a
In archive libfoo.a:

libfoo.o: file format pe-i386

SYMBOL TABLE:
[ 0](sec -2)(fl 0x00)(ty 0)(scl 103) (nx 1) 0x00000000 foo.c
File
*[ 2](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 1) 0x00000000 _bar*
AUX tagndx 0 ttlsiz 0x0 lnnos 0 next 0
[ 4](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .text
AUX scnlen 0xa nreloc 1 nlnno 0
[ 6](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .data
AUX scnlen 0x0 nreloc 0 nlnno 0
[ 8](sec 3)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .bss
AUX scnlen 0x0 nreloc 0 nlnno 0
[ 10](sec 4)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .rdata
AUX scnlen 0x4 nreloc 0 nlnno 0
[ 12](sec 5)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .rdata$zzz
AUX scnlen 0x2a nreloc 0 nlnno 0
[ 14](sec 6)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .eh_frame
AUX scnlen 0x38 nreloc 1 nlnno 0

Notice the _bar, now you need to check if libippi exported it as
ippithreshold_ltvalgtval_8u_c1ir, _ippithreshold_ltvalgtval_8u_c1ir or
ipp__ippithreshold_ltval_8u_c1ir. :-)

--
Silvio Clécio
silvioprog
2017-03-14 15:45:31 UTC
Permalink
Post by silvioprog
[...]
Error: Undefined symbol: IPP__IPPITHRESHOLD_LTVAL_8U_C1
IR$PIPP8U$LONGINT$IPPISIZE$BYTE$BYTE$$IPPSTATUS
Post by silvioprog
function _ippiThreshold_LTValGTVal_8u_C1IR(pSrcDst: PIpp8u; srcDstStep: int;
roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u;
thresholdGT: Ipp8u;
valueGT: Ipp8u): IppStatus; external;
{$linklib libippi}
Error: Undefined symbol: IPP__IPPITHRESHOLD_LTVAL_8U_C1
IR$PIPP8U$LONGINT$IPPISIZE$BYTE$BYTE$$IPPSTATUS
(same error if I add: {$linklib ippi} or {$linklib libippi} ... ippi.lib
and libippi.a are in directory where -Fl points)
Post by silvioprog
fix 1: check which convention your library was compiled,
I think it is stdcall and I have this calling convention there (extdecl
int; roiSize: IppiSize; threshold: Ipp8u; value: Ipp8u): IppStatus;
extdecl; external;
Awesome. Now we need to check how libippi had exported its symbols. :-)
For example, to check the symbols from the libfoo.a sent in my previous
$ objdump -t libfoo.a
libfoo.o: file format pe-i386
[ 0](sec -2)(fl 0x00)(ty 0)(scl 103) (nx 1) 0x00000000 foo.c
File
*[ 2](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 1) 0x00000000 _bar*
AUX tagndx 0 ttlsiz 0x0 lnnos 0 next 0
[ 4](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .text
AUX scnlen 0xa nreloc 1 nlnno 0
[ 6](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .data
AUX scnlen 0x0 nreloc 0 nlnno 0
[ 8](sec 3)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .bss
AUX scnlen 0x0 nreloc 0 nlnno 0
[ 10](sec 4)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .rdata
AUX scnlen 0x4 nreloc 0 nlnno 0
[ 12](sec 5)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .rdata$zzz
AUX scnlen 0x2a nreloc 0 nlnno 0
[ 14](sec 6)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .eh_frame
AUX scnlen 0x38 nreloc 1 nlnno 0
Notice the _bar, now you need to check if libippi exported it as
ippithreshold_ltvalgtval_8u_c1ir, _ippithreshold_ltvalgtval_8u_c1ir or
ipp__ippithreshold_ltval_8u_c1ir. :-)
I forgot a question, could you send your ippi .a files for us? If so, I can
try a test here. :-)
--
Silvio Clécio
LacaK
2017-03-15 07:38:18 UTC
Permalink
Error: Undefined symbol:
IPP__IPPITHRESHOLD_LTVAL_8U_C1IR$PIPP8U$LONGINT$IPPISIZE$BYTE$BYTE$$IPPSTATUS

test 2: put the library implementation below function
declaration, eg:

function _ippiThreshold_LTValGTVal_8u_C1IR(pSrcDst: PIpp8u;
srcDstStep: int;
roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u;
thresholdGT: Ipp8u;
valueGT: Ipp8u): IppStatus; external;
{$linklib libippi}

here I get:
Error: Undefined symbol:
IPP__IPPITHRESHOLD_LTVAL_8U_C1IR$PIPP8U$LONGINT$IPPISIZE$BYTE$BYTE$$IPPSTATUS
(same error if I add: {$linklib ippi} or {$linklib libippi} ...
ippi.lib and libippi.a are in directory where -Fl points)


fix 1: check which convention your library was compiled,

I think it is stdcall and I have this calling convention there
(extdecl is macro: {$DEFINE extdecl:=stdcall} ):
function _ippiThreshold_LTVal_8u_C1IR(pSrcDst: PIpp8u;srcDstStep:
int; roiSize: IppiSize; threshold: Ipp8u; value: Ipp8u): IppStatus;
extdecl; external;
Post by silvioprog
Awesome. Now we need to check how libippi had exported its
symbols. :-) For example, to check the symbols from the libfoo.a
$ objdump -t libfoo.a
libfoo.o: file format pe-i386
[ 0](sec -2)(fl 0x00)(ty 0)(scl 103) (nx 1) 0x00000000 foo.c
File
*[ 2](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 1) 0x00000000 _bar*
AUX tagndx 0 ttlsiz 0x0 lnnos 0 next 0
[ 4](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .text
AUX scnlen 0xa nreloc 1 nlnno 0
[ 6](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .data
AUX scnlen 0x0 nreloc 0 nlnno 0
[ 8](sec 3)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .bss
AUX scnlen 0x0 nreloc 0 nlnno 0
[ 10](sec 4)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .rdata
AUX scnlen 0x4 nreloc 0 nlnno 0
[ 12](sec 5)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .rdata$zzz
AUX scnlen 0x2a nreloc 0 nlnno 0
[ 14](sec 6)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .eh_frame
AUX scnlen 0x38 nreloc 1 nlnno 0
Notice the _bar, now you need to check if libippi exported it as
ippithreshold_ltvalgtval_8u_c1ir, _ippithreshold_ltvalgtval_8u_c1ir or
ipp__ippithreshold_ltval_8u_c1ir. :-)
I forgot a question, could you send your ippi .a files for us? If so,
I can try a test here. :-)
Yes of course: I have uploaded them here
http://uschovna.zoznam.sk/download?code=1342688547227-EZyyeVzToDVVkkbJNCbN
But be aware of that I am on Windows, not Linux (Despite this I have
added to ZIP also .a files as they are installed by Intel into direcotry
"Linux". In direcory "Windows" are installed only .lib files).
If I can repeat my question: Can I use ".a" libraries also on Windows ?
If not can I use ".lib" created by C/C++ (I do not know how they are build)
Thank you
-Laco.
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/li
silvioprog
2017-03-19 03:52:20 UTC
Permalink
Post by silvioprog
I forgot a question, could you send your ippi .a files for us? If so, I
Post by silvioprog
can try a test here. :-)
Yes of course: I have uploaded them here http://uschovna.zoznam.sk/down
load?code=1342688547227-EZyyeVzToDVVkkbJNCbN
But be aware of that I am on Windows, not Linux (Despite this I have added
to ZIP also .a files as they are installed by Intel into direcotry "Linux".
In direcory "Windows" are installed only .lib files).
If I can repeat my question: Can I use ".a" libraries also on Windows ? If
not can I use ".lib" created by C/C++ (I do not know how they are build)
Thank you
-Laco.
Unfortunately you can't use the static libraries (.a) of Intel because they
are generated for Linux, in spite of static libraries be cross-platform.

I'm not sure about the .lib files. MS's COFF files adopt the .lib
extension, but it is a little bit strange these sizes below:

`libippi.a`:
. original - 251 MB;
. striped - 192 MB.

`libippi.lib`:
. original - 853 KB;
. striped - no strip needed, it is already small.

Huge difference, so I'm not sure if the .lib are really COFF files (even
the owns MS COFF style). I tried to convert it to OMF (the .obj for testing
on Delphi, because I don't know if FPC supports OMF) via the VS LIB.EXE
tool and I didn't have success. The .obj was generated, but it doesn't work
because it was generated with only the library "interface", so I'm
suspecting the `libippi.lib` requires external libraries, something like
other .libs or .dlls, because 853 KB is a very small size for the same
library that requires 250 MB on Linux... you need to check about it at
Intel support (or trying it in C or C++ just to check if these .lib files
are really OK).

Anyway, I'm on Linux and I did this test below, it worked fine (just
sharing it, but I know you need it on Windows :-) ):

type
cchar = AnsiChar;
Pcchar = PAnsiChar;
cint = Int32;

IppLibraryVersionPtr = ^IppLibraryVersion;
IppLibraryVersion = record
major: cint;
minor: cint;
majorBuild: cint;
build: cint;
targetCpu: packed array [0 .. 3] of cchar;
Name: Pcchar;
Version: Pcchar;
BuildDate: Pcchar;
end;

function ippGetLibVersion: IppLibraryVersionPtr; cdecl; external;
{$LINKLIB ippcore.a}
{$LINKLIB ippi.a}

var
ver: IppLibraryVersionPtr;
begin
ver := ippGetLibVersion;
writeln(ver^.Version);
end.

// result: 2017.0.2 (r54644)
--
Silvio Clécio
Sven Barth via fpc-devel
2017-03-19 08:43:16 UTC
Permalink
Post by silvioprog
Post by LacaK
Post by silvioprog
I forgot a question, could you send your ippi .a files for us? If so, I
can try a test here. :-)
Post by silvioprog
Post by LacaK
Yes of course: I have uploaded them here
http://uschovna.zoznam.sk/download?code=1342688547227-EZyyeVzToDVVkkbJNCbN
Post by silvioprog
Post by LacaK
But be aware of that I am on Windows, not Linux (Despite this I have
added to ZIP also .a files as they are installed by Intel into direcotry
"Linux". In direcory "Windows" are installed only .lib files).
Post by silvioprog
Post by LacaK
If I can repeat my question: Can I use ".a" libraries also on Windows ?
If not can I use ".lib" created by C/C++ (I do not know how they are build)
Post by silvioprog
Post by LacaK
Thank you
-Laco.
Unfortunately you can't use the static libraries (.a) of Intel because
they are generated for Linux, in spite of static libraries be
cross-platform.

Non-sense. Static libraries are as platform specific as any other binary
code, after all it needs to call OS functions.
Post by silvioprog
I'm not sure about the .lib files. MS's COFF files adopt the .lib
. original - 251 MB;
. striped - 192 MB.
. original - 853 KB;
. striped - no strip needed, it is already small.
Seems like the second one is merely an import library for the DLL instead
of a real static library.
And of course that is COFF as well. MSVC only supports COFF.

Regards,
Sven
silvioprog
2017-03-19 19:28:11 UTC
Permalink
On Sun, Mar 19, 2017 at 5:43 AM, Sven Barth via fpc-devel <
Post by silvioprog
Unfortunately you can't use the static libraries (.a) of Intel because
they are generated for Linux, in spite of static libraries be
cross-platform.
Non-sense. Static libraries are as platform specific as any other binary
code, after all it needs to call OS functions.
Well, I understand by cross-platform anything that is implemented on
multiple platforms, so once ar archives can be generated for multiple ones,
it makes sense for me. :-)
Post by silvioprog
I'm not sure about the .lib files. MS's COFF files adopt the .lib
Post by silvioprog
. original - 251 MB;
. striped - 192 MB.
. original - 853 KB;
. striped - no strip needed, it is already small.
Seems like the second one is merely an import library for the DLL instead
of a real static library.
Indeed.

And of course that is COFF as well. MSVC only supports COFF.
There isn't only one kind of COFF, AFAIK MS has an own COFF style and MSVC
supports only that. Sure, Intel must have used MSVC ones. However, my
*suggestion* about LacaK confirming that was just because he can generate
an object or a shared library from a MS COFF file, solving his problem!

--
Silvio Clécio

Adriaan van Os
2017-03-14 14:38:03 UTC
Permalink
Post by LacaK
Hi,
I have C/C++ librarby (".lib" for Windows and ".a" for Linux) from Intel
IPP package (they distribute ".lib" and also ".dll" for Windows and ".a"
for Linux)
Note that you can download my ipp FPC interfaces here <http://adriaan.biz/intel/ipp.pas.zip>. I do
link with statically with success on Mac OS X.

Regards,

Adriaan van Os

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listi
Ladislav Karrach
2017-03-14 15:15:55 UTC
Permalink
Post by Adriaan van Os
Note that you can download my ipp FPC interfaces here
<http://adriaan.biz/intel/ipp.pas.zip>. I do link with statically with
success on Mac OS X.
Yes I am aware of your port and I have downloaded it, but I am on
Windows and I cannot succeed in statically linking on Windows ...
L.


_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-deve
Loading...