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.

"LacaK" wrote

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;

IPP_IPPITHRESHOLD_LTVALGTVAL_8U_C1IR$PIPP8U$LONGINT$IPPISIZE$BYTE$BYTE$BYTE$BYTE$$IPPSTATUS

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

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;

IPP_IPPITHRESHOLD_LTVALGTVAL_8U_C1IR$PIPP8U$LONGINT$IPPISIZE$BYTE$BYTE$BYTE$BYTE$$IPPSTATUS

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

.
.

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

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

On Tue, Mar 14, 2017 at 10:36 AM, Sven Barth via fpc-devel <

wrote:

[...]

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".

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

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

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)

I am doing something wrong or just this is not possible ? Thank you -Laco.

On Tue, Mar 14, 2017 at 11:57 AM, silvioprog wrote: [...]

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 ...

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. ^^'

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.

Dňa 14.3.2017 o 15:57 silvioprog napísal(a):

here I get (without {$linklib}):
Error: Undefined symbol:
IPP__IPPITHRESHOLD_LTVAL_8U_C1IR$PIPP8U$LONGINT$IPPISIZE$BYTE$BYTE$$IPPSTATUS

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;

-Laco.

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.

LacaK wrote

Dňa 14.3.2017 o 15:57 silvioprog napísal(a):

[...]

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. :-)

I forgot a question, could you send your ippi .a files for us? If so, I can try a test here. :-)

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;

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.

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.

Dňa 15.3.2017 o 12:54 Yury Sidorov napísal(a):

But does it works also on Windows ? (as far as I does not have "objdump" utility there?)
L.

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.

Regards,
Sven

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 [ 5](sec 3)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 [ 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.

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.

"LacaK" wrote

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

Yes, the Windows one only supports PE, not ELF.

Regards,
Sven

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.

Hi,

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

Dňa 16.3.2017 o 10:03 Karoly Balogh (Charlie/SGR) napísal(a):

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, ...)

-Laco

LacaK wrote

Then I get: test_IPP.lpr(17,1) Error: undefined reference to `ippGetLibVersion' (I have tried also: _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
'';

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.

- 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.

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.

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
'';

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.

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.

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)

"silvioprog" wrote

On Wed, Mar 15, 2017 at 4:38 AM, LacaK wrote: >> >> 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)

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.

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:

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

On Sun, Mar 19, 2017 at 5:43 AM, Sven Barth via fpc-devel <

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. :-)

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!