Problems linking

[the_ether]

I've just downloaded the evaluation version of the Windows version of IPP and am having problems linking.

I'm using a MinGW environment and in my makefile I have included -lippi -lippcore. I don't get any complaints about finding the libraries butI do keep on getting "In function `dsputil_init_mmx':
dsputil_mmx.c:2608: undefined reference to `ippiDCT8x8Fwd_16s_C1I@4'
collect2: ld returned 1 exit status"

Any ideas?

[Vladimir_Dudnik]

Hi,

m-m-m, we did not test IPP with MinGW environment, you can refer to the full list of supported hardware and software in IPP documentation.Does MinGW support stdcall calling convention?

Regards,
Vladimir

[the_ether]

Thanks for your rpely.

You seem to have spotted the problem. MinGW does add an underscore to function names BUT not if it is producing a DLL - which is what I'm trying to do. So, how do I strip the underscore from function names in the IPP libs, or do i simply use the Linux version of the IPP?

g.

[the_ether]

Okay, having spent another full day on this I have learnt the following:

- the IPP DLLs do NOT use any underscore or '@x' suffix but MinGW / Gnu does

- to fix things I need to pull out all the function names from the IPP DLLs into aDEF file

- I then need to manually edit the DEF file and add aliases to the function names I want to use, eg:

LIBRARY ippi.dll

EXPORTS

ippiDCT8x8Fwd_16s_C1I

ippiDCT8x8Fwd_16s_C1I@4 = ippiDCT8x8Fwd_16s_C1I

_ippiDCT8x8Fwd_16s_C1I@4 = ippiDCT8x8Fwd_16s_C1I

- I then need to create a new LIB files based on the DEF and DLL and link that.

However, I now get "error at loading of ippIP library. No DLLs were found in the Waterfall procedure."

I think to fix this I need to statically link the ippi library but I'm not sure how to do that. I only have the evaluation version of IPP which doesn't include the static libs and I don't want to buy IPP until I'm sure I can get it all to work.

Any ideas?

(I am using MinGW to produce a DLL and want to link the Windows version of IPP to the DLL I am producing under MinGW).

g.

[Vladimir_Dudnik]

Hi,

if you done all correct, there should not be problem with IPP. By the way, it seems to be very popular question about that message "error at loading of ippIP library. No DLLs were found in the Waterfall procedure." You can try to find this string in the forum to find the answer.

If shortly, you need to specify path to IPP DLL in your PATH environment variable.

Regards,
Vladimir

[the_ether]

Thanks Vladimir, you're right. I did a search on the Net before you suggested it but the other person simply solved the problem by statically linking - which I couldn't do as I don't have the static libs as I am just trialing the evaluation version of IPP. The problem was indeed the path variables.

It was confusing because I previously got errors complaining that it couldn't find DLLs and when I copied them into the same directory they went away - only to be replaced by this Waterfall error.

Reading yet further into the docs I saw that there is a batch file in IntelIPP5.0ia32 oolsenv that sets the environment vars. This doesn't seem to work as there are no newline characters between the different commands. I therefore entered them manually into a command window and now it all works.

So the two problems seems to be:

- the naming of functions in the Intel IPP DLLs. To fix, Intel ought to add aliases of the function names that include the preceeding underscore and the '@x' suffix, that way, both naming conventions can be used

- add newline characters to ippenv.bat

g.

[Vladimir_Dudnik]

Hi,

I'm not sure that there is some problem with calling convention used in IPP. We use just stdcall convention. Note, Microsoft Windows kernel DLLs use the same naming convention, so how did you link with kernel32.lib, gdi32.lib user32.lib?Does Mingwsupport stdcall?

Thanks for pointing to the problem with BAT file, I'll pass that issue to the appropriate people. Btw, you also can submit issue report to Intel Technical Support.

Regards,
Vladimir

[the_ether]

Hello Vdudnik

You know, I get better support from you than I do from Intel's official "Premier" support.

Regarding naming convention, all I can say is what I've learnt over the last 2 days. The following website was very useful:

www.geocities.com/yongweiwu/stdcall.htm

A pertinentexcerpt is:

The internal representations of both __cdecl and __stdcall functions have decorations. In MSVC (Microsoft Visual C++) and MinGW (Minimalistic GNU for Windows) GCC, __cdecl function will be prefixed an underscore, and __stdcall functions will have the beginning underscore as well as be appended by the at-sign (@) followed by the number of bytes in the argument list. So, double __cdecl sin(double) will be decorated as _sin, and double __stdcall sin(double) will be decorated as _sin@8.

But things are not that simple. The decorations could change when they appear in DLLs or when they are produced by different compilers. The following table lists the names as are produced by MSVC, MinGW, Digital Mars C/C++ Compiler (DMC), Borland C++ Compiler/C++ Builder (BCC):

Calling ConventionInternal*MSVC DLL (w/ DEF)MSVC DLL (dllexport)DMC DLLMinGW DLLBCC DLL__stdcall_Function@nFunction_Function@n_Function@nFunction@nFunction__cdecl_FunctionFunctionFunctionFunctionFunction_Function

* For all but BCC, which has the same naming convention for symbols in code and exported name in DLL.

The naming convention in the Intel DLLs are as in the above table under "MSVC DLL (w DEF)". Note that someone on Intel Premier support claimed that the naming convention is as listed under "MSVC DLL (dllexport / __stdcall", but that is not correct.

Anyway, to solve future problems, it would be best if Intel included aliases in their libraries. I have told Premier support that but have not heard anything from them since their first (wrong) suggestion two days ago.

Thanks again for your suggestions.

g.

[Vladimir_Dudnik]

thank you, in any case, if you mentioned this issue to Technical Support, it means that this issue will be reviewedat next IPP version planning stage. So, actual decision will be made that time.

Regards,
Vladimir