cannot link

cannot link

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

20 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

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

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

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

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

Regards, Sergey

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

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

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

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

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

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

Quoting Filip KrolupperCool, 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 ;-)

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

Quoting Filip KrolupperI 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

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

Best Reply

Filip,Look how IPP functions are declared. Let's take a function from IPPIIPPAPI( Ipp8u*, ippiMalloc_8u_C1, ( int widthPixels, int heightPixels, int* pStepBytes ) )How IPPAPI is defined?

#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

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?
#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

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

Regards, Sergey

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

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









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

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

Login to leave a comment.