cannot link

[Filip_Krolupper]

I get this error message:
>Deconvolution.obj : error LNK2019: unresolved external symbol _ippiFFTInv_PackToR_32f_C1IR referenced in function "signed char __cdecl MyIppBasedCorrelation(float *,float *,float *,unsigned int,unsigned int,unsigned char *,int,struct FFT2DSpec_R_32f *)" (?MyIppBasedCorrelation@@YACPAM00IIPAEHPAUFFT2DSpec_R_32f@@@Z)

and many others linker error.

This I get when compiling 32 bits my own dll library. When compiling 64 bits everything goes well. The next strange thing is that when I use the same code building standalone application 32 adn 64 bits works both flawlesly. I checked compiler settings, paths hundred times and nearly ready to go to my shrink.

any ideas?

thanks

Filip

[Gennady_F_Intel]

that's really strange, have you checked dependencis 32 version of your dll from 32 bit's version of ippi, ippcore and etc..?

[Filip_Krolupper]

Well, I'm using ippi functions so I tried to add as input to the linker ippi.lib ippcore.lib .... no success. As the time goes I tried to add all others libs. Then I suspected the system that it uses wrong path, because of some stupid setting that I'm not able determine. So I deleted all input linker settings and copied right libs to my place and told the linker to use it from the new place. Again no success. I tried to reinstall IPP, I checked system paths. Btw static linkage doesn't work as well. Dont know what to do now.

I suspect there can be some preprocessor setting, that is wrong, but not sure about it. Anyway this thing drives me crazy, because I wanted to release my app last week. The worst thing is, that I know that IPP works great in my regular work - we use it every day, but my own installation sucks. This is a clear proof, that there is something wrong between my chair and my keyboard ;-)

Filip

[SergeyKostrov]

Hi Filip,

Here are a couple of things to consider:

- Did you try to compile the application on a different computer?

- Did you try to compare your IPP installation withIPP installation on a different computer?

- How many IPPinstallations do you have on your computer?

- Did you check SET and PATH environment variables?

- Did you check a Visual Studio's options?

'Main Menu -> Tools -> Options -> Project and Solutions -> VC++ Directories -> Include Files & Library Files'

- Would you be able to create a simple reproducer of the link error LNK2019?

Best regards,
Sergey

[Sergey_K_Intel]

Quoting Filip Krolupper

I get this error message:
>Deconvolution.obj : error LNK2019: unresolved external symbol _ippiFFTInv_PackToR_32f_C1IR referenced in function "signed char __cdecl MyIppBasedCorrelation(float *,float *,float *,unsigned int,unsigned int,unsigned char *,int,struct FFT2DSpec_R_32f *)" (?MyIppBasedCorrelation@@YACPAM00IIPAEHPAUFFT2DSpec_R_32f@@@Z)

Hi Filip,

In fact the name of this function in the library (mangled name) is "_ippiFFTInv_PackToR_32f_C1IR@16". This is how the function names stored in libraries.

Usually the absence of "@XX" suffix means, that corresponding function declaration (prototype) doesn't get MS "__stdcall" attribute. Look at the compilation stage warnings, try to find out where you missed correct function declaration.

Regards,
Sergey

[Filip_Krolupper]

Hi,
I tried today link the solution on 2 different workstations (different installation of IPP), but got the same result. Linker error.

Sergey, thanks very much. In fact I tried to check ippi.lib file and I found out the same thing as you(I mean the suffix @xx is missing, but I'm not that familiar with compilers so I had no idea what does it mean). In this time I dont know how to tell VS 2005 compiler to use _stdcall atribubute for these functions. Will google it a little, and I'll hopefully solve it somehow.

regards

Filip

[SergeyKostrov]

Quoting Filip Krolupper

...I checked compiler settings,...

Did you check Linker settings? This is a Linker error and it is not related to a "wrong" declaration of the
IPP function 'ippiFFTInv_PackToR_32f_C1IR'.

As you stated you managed to compile and linka 64-bit configuration. Then, for a 32-bitconfiguration
compilation was successful, but it fails to link IPP libraries.

A Linker error:

LNK2019: unresolved external symbol _ippiFFTInv_PackToR_32f_C1IR

means thatsome IPP library from Image Processing domain is not included for a32-bit configuration.

Best regards,
Sergey

[Filip_Krolupper]

Sergey Kostrov: yes, I checked even the linker. In VS are linker and compiler settings in the same window ;-)

[Filip_Krolupper]

I feel that we are very close. If I change code generation settings "Calling convention" from _cdecl to _stdcall the library is linked without error. The problem is that I need to use _cdecl calling convention because my DLL is PS plugin in fact. PS cant work with _stdcall library, it crashes. As I said before, 64 bits version works well as PS plugin, it links without error for _cdecl calling convention. Have to point out that I use VS2005.

Filip

[Filip_Krolupper]

Ehm, little bit confused. Haven't changed anything in 64 bits and it just began to report the same error. Humpf :-(

[Filip_Krolupper]

Cool, total chaos ;-) I added _WIN32WCE to preprocessor and 32 bit works, but 64 bit doesn't. One more day and I'll forget this mess and will return to my own libraries ;-)

[SergeyKostrov]

Quoting Filip Krolupper

Cool, total chaos ;-) I added _WIN32WCE to preprocessor

[SergeyK] Agree.It looks like a"surprize" from Microsoft.Did you add that macroin a source file,
or in a project settings? You can add that macro for a32-bit configuration only in a
project settings for'Preprocessor '

and 32 bit works, but 64 bit doesn't. One more day and I'll forget this mess and will return to my own libraries ;-)

[Filip_Krolupper]

I did it in project settings - I checked ippi.h and _WIN32WCE causes undef of __stdcall.

[SergeyKostrov]

Quoting Filip Krolupper

I did it in project settings - I checked ippi.h and _WIN32WCE causes undef of __stdcall.

I use _WIN32WCE macro for Embedded platforms andI couldn't imaging that it couldaffect calling conversions in IPP.

So, is that a bug or a feature of IPP? What do you think?

Best regards,
Sergey

[Filip_Krolupper]

I dont think so. I use IPP in my regular work every day and it works. Its some mess in my code. Unfortunatelly I have no idea how to fix it to use IPP. Will give a try one more day. If I fail, I'll leave it.

regards

Filip

[Sergey_K_Intel · Accepted solution]

Filip,

Look how IPP functions are declared. Let's take a function from IPPI

IPPAPI( Ipp8u*, ippiMalloc_8u_C1, ( int widthPixels, int heightPixels, int* pStepBytes ) )

How IPPAPI is defined?

[cpp]#if !defined( IPPAPI ) #if defined( IPP_W32DLL ) && (defined( _WIN32 ) || defined( _WIN64 )) #if defined( _MSC_VER ) || defined( __ICL ) #define IPPAPI( type,name,arg ) __declspec(dllimport) type __STDCALL name arg; #else #define IPPAPI( type,name,arg ) type __STDCALL name arg; #endif #else #define IPPAPI( type,name,arg ) type __STDCALL name arg; #endif #endif [/cpp]

The line 9 aboveis the definition which must work in your case if you don't use IPP DLLs. And, the last, how __STDCALL is defined?

[cpp]#if defined( _WIN32 ) || defined ( _WIN64 ) #define __STDCALL __stdcall #define __CDECL __cdecl #define __INT64 __int64 #define __UINT64 unsigned __int64 #else #define __STDCALL #define __CDECL #define __INT64 long long #define __UINT64 unsigned long long #endif [/cpp]

So, all you need is to make sure _WIN32 or _WIN64 is defined. This must be done by MS compiler automatically(this is one of pre-defined macros, I believe even for VS2005 compiler). _WIN32 is defined for both x86/AMD64 platforms. _WIN64 for AMD64 building platform only.

Don't use _WIN32WCE unless you build for Windows CE )). BTW, you can use /E compilation option to get preprocessed file in the form it gets to compiler after all #ifdef parsed. If you see "#define __STDCALL", this will mean you have missed correct definition.

Good luck,

Sergey

[Filip_Krolupper]

Hi guys, problem solved. I use some other library where was defined __stdcall as an empty string. When I deleted that definition, it starts to work suddently. Guys, how I hate these kind of problems ;-)

thank you all

Filip

[Ying_H_Intel]

How classical problem! thanks for the sharing.
Add some relatedinformation from Intel Compiler documentation,

Naming Conventions inC/C++

C	cdecl (default)	name (Linux OS) _name (Windows OS) _name (Mac OS X)	Mixed case preserved
C (Windows OS only)	__stdcall	_name@n	Mixed case preserved
C++	Default	name@@decoration (Linux OS) _name@@decoration (Windows OS) __decorationnamedecoration (Mac OS X)	Mixed case preserved

In the preceding table:

• The leading underscore (such as _name) is used on Windows operating systems based on IA-32 architecture only.

• @n represents the stack space, in decimal notation, occupied by parameters on Windows operating systems based on IA-32 architecture only.

For example, assume a function is declared in C as:

  extern int __stdcall Sum_Up( int a, int b, int c );

Each integer occupies 4 bytes, so the symbol name placed in the .OBJ file on systems based on IA-32 architecture is:

  _Sum_Up@12

On systems based on Intel 64 architecture, the symbol name placed in the .OBJ file is:

  Sum_Up
Thanks
Ying H

[Filip_Krolupper]

Thank you guys again. I got it. Unfortunatelly I found another problem, which is in IPPI fourier transform implementation. So count with me:

1)setup size increase +70%
2)linking problems (4 days)
3)AMD processor issues
4)Ipp FT problem

.... and the overal speedup is about 20%.

in other words, I quit, IPP means for me more problems than benefits.

thank you again and peace :-)

Filip

[SergeyKostrov]

Quoting Filip Krolupper

...in other words, I quit, IPP means for me more problems than benefits...

I'm really sorry to hear that. What are you going to use instead?

Best regards,
Sergey