Linking problems with IPP 6.0 Evaluation (Windows + VS 2008)

Linking problems with IPP 6.0 Evaluation (Windows + VS 2008)

Hello,

again it's me. I tried to make some tests for using the IPP 6.0 (Evaluation)in Visual Studio 2008.

The scenario is this:
An C++-library (called A)without CLR includesIPP-function at some points of code.
An C++-application (called P)(also without CLR) links this library and executes some functions of the lib.

Now the problems:
Linking the ipp dynamically into A, is no problem, but linking then A into P causes the error:

fatal error LNK1107: invalid or corrupt file: cannot read at 0x2A8 (library A)

Linking the ipp statically into A is also no problem, but linking then A into P causes these errors (while linking ippiemerged.lib) :
Error1error LNK2001: unresolved external symbol _p8_ippiAbs_32f_C1IR@16LibraryA.lib
Error2error LNK2001: unresolved external symbol _v8_ippiAbs_32f_C1IR@16LibraryA.lib
Error3error LNK2001: unresolved external symbol _t7_ippiAbs_32f_C1IR@16LibraryA.lib
Error4error LNK2001: unresolved external symbol _w7_ippiAbs_32f_C1IR@16LibraryA.lib
Error5error LNK2001: unresolved external symbol _px_ippiAbs_32f_C1IR@16LibraryA.lib
Error6error LNK2019: unresolved external symbol _ippJumpIndexForMergedLibs referenced in function _ippiAbs_32f_C1IR@16LibraryA.lib
Error7error LNK2001: unresolved external symbol _ippJumpIndexForMergedLibsLibraryA.lib
Error8error LNK2001: unresolved external symbol _p8_ippiConvValid_32f_C1R@40LibraryA.lib
Error9error LNK2001: unresolved external symbol _v8_ippiConvValid_32f_C1R@40LibraryA.lib
Error10error LNK2001: unresolved external symbol _t7_ippiConvValid_32f_C1R@40LibraryA.lib
Error11error LNK2001: unresolved external symbol _w7_ippiConvValid_32f_C1R@40LibraryA.lib
Error12error LNK2001: unresolved external symbol _px_ippiConvValid_32f_C1R@40LibraryA.lib

I also tried nearly the same in the CLR-Environment. But without success:
http://software.intel.com/en-us/forums/showthread.php?t=63790

Thanksfor help

mw

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

Quoting - mweissbach
Hello,

again it's me. I tried to make some tests for using the IPP 6.0 (Evaluation)in Visual Studio 2008.

The scenario is this:
An C++-library (called A)without CLR includesIPP-function at some points of code.
An C++-application (called P)(also without CLR) links this library and executes some functions of the lib.

Now the problems:
Linking the ipp dynamically into A, is no problem, but linking then A into P causes the error:

fatal error LNK1107: invalid or corrupt file: cannot read at 0x2A8 (library A)

Linking the ipp statically into A is also no problem, but linking then A into P causes these errors (while linking ippiemerged.lib) :
Error1error LNK2001: unresolved external symbol _p8_ippiAbs_32f_C1IR@16LibraryA.lib
Error2error LNK2001: unresolved external symbol _v8_ippiAbs_32f_C1IR@16LibraryA.lib
Error3error LNK2001: unresolved external symbol _t7_ippiAbs_32f_C1IR@16LibraryA.lib
Error4error LNK2001: unresolved external symbol _w7_ippiAbs_32f_C1IR@16LibraryA.lib
Error5error LNK2001: unresolved external symbol _px_ippiAbs_32f_C1IR@16LibraryA.lib
Error6error LNK2019: unresolved external symbol _ippJumpIndexForMergedLibs referenced in function _ippiAbs_32f_C1IR@16LibraryA.lib
Error7error LNK2001: unresolved external symbol _ippJumpIndexForMergedLibsLibraryA.lib
Error8error LNK2001: unresolved external symbol _p8_ippiConvValid_32f_C1R@40LibraryA.lib
Error9error LNK2001: unresolved external symbol _v8_ippiConvValid_32f_C1R@40LibraryA.lib
Error10error LNK2001: unresolved external symbol _t7_ippiConvValid_32f_C1R@40LibraryA.lib
Error11error LNK2001: unresolved external symbol _w7_ippiConvValid_32f_C1R@40LibraryA.lib
Error12error LNK2001: unresolved external symbol _px_ippiConvValid_32f_C1R@40LibraryA.lib

I also tried nearly the same in the CLR-Environment. But without success:
http://software.intel.com/en-us/forums/showthread.php?t=63790

Thanksfor help

mw

You need to link also ippimerged.lib and ippcore.lib to resolve the latter errors.
Regards

Quoting - elhefe38

You need to link also ippimerged.lib and ippcore.lib to resolve the latter errors.
Regards

I tried this and I gotthe following messages:

Warning1warning LNK4221: no public symbols found; archive member will be inaccessibleippimerged.lib
Warning2warning LNK4221: no public symbols found; archive member will be inaccessibleippimerged.lib
Warning3warning LNK4221: no public symbols found; archive member will be inaccessibleippimerged.lib
Warning4warning LNK4221: no public symbols found; archive member will be inaccessibleippimerged.lib
Warning5warning LNK4221: no public symbols found; archive member will be inaccessibleippimerged.lib
Warning6warning LNK4221: no public symbols found; archive member will be inaccessibleippimerged.lib
Warning7warning LNK4221: no public symbols found; archive member will be inaccessibleippimerged.lib
Warning8warning LNK4221: no public symbols found; archive member will be inaccessibleippimerged.lib
Warning9warning LNK4221: no public symbols found; archive member will be inaccessibleippimerged.lib
Warning10warning LNK4221: no public symbols found; archive member will be inaccessibleippimerged.lib
Warning11warning LNK4221: no public symbols found; archive member will be inaccessibleippimerged.lib
Warning12warning LNK4221: no public symbols found; archive member will be inaccessibleippimerged.lib
Error13error LNK2019: unresolved external symbol _ippiAbs_32f_C1IR@16 referenced in function "public: int __thiscall cMySpecialClass::process(float const *,unsigned int,struct sSize)" (?process@cMySpecialClass@@QAEHPBMIUsSize@@@Z)LibraryA.lib
Error14error LNK2019: unresolved external symbol _ippiConvValid_32f_C1R@40 referenced in function "public: int __thiscall cMySpecialClass::process(float const *,unsigned int,struct sSize)" (?process@cMySpecialClass@@QAEHPBMIUsSize@@@Z)LibraryA.lib

Error15fatal error LNK1120: 2 unresolved externalsX:IppTestprogramDebugmyProgram.exe

That seems very strange. I don't know why this errors occur. In my opinion, the linker should find all files. Can the problem located in the matter of C++-Program includes C-library?

Thanks for answers

mw

Quoting - elhefe38

You need to link also ippimerged.lib and ippcore.lib to resolve the latter errors.
Regards

I not sure what you're currently linking with, but when I start a new project that statically links with IPP I do something like the following:

For sequential execution link with:
ipp*emerged.lib
ipp*merged.lib
ippcorel.lib

For threaded execution link with:
ipp*emerged.lib
ipp*merged_t.lib
ippcore_t.lib
libiomp5md.lib - will require libiomp5md.dll

Replace the * above with the IPP section of interest such as 'i' for image processing and 'cv' for computer vision (you may need to include several of them depending on which sections are being used). the emerged libraries provide the dispatching so that the correct version of the IPP routine is executed based on the CPU being used (assuming you called ippStaticInit()). Once you get over the initial linking learning curve, it becomes very nice to have so many linking options, for example I build IPP dependent libraries with both threaded and sequential configurations.

Peter

The problem is solved:

There seems to be no way to create in VS 2008 a library out of the IPP (neither static nor dynamic). Since the Program P includes the objectFiles of the (dynamic) libraryand the ipp (the stuplibs), it can be compiled and used.

This works for /clr and for non-/clr programs

Thanks all for your help

mw

Quoting - mweissbach
There seems to be no way to create in VS 2008 a library out of the IPP (neither static nor dynamic). Since the Program P includes the objectFiles of the (dynamic) libraryand the ipp (the stuplibs), it can be compiled and used.

I am not sure about your exact thoughts but you _can_ create a library (at least dynamic, I did it) using IPP...

Regards

Quoting - elhefe38

I am not sure about your exact thoughts but you _can_ create a library (at least dynamic, I did it) using IPP...

Regards

I believe, that this is possible. But VS 2008 always complaint about a wrong or currupt library while including / linking.
Since this are tests with the evalutation Version, I don't need this. In the case we buy the IPP, compiling libs will be obligatory.
But nevertheless, can you give me advise, how to build dynamic and static libs - in case this procedure differs from the documentation?

Thanks

mw

Quoting - mweissbach

I believe, that this is possible. But VS 2008 always complaint about a wrong or currupt library while including / linking.
Since this are tests with the evalutation Version, I don't need this. In the case we buy the IPP, compiling libs will be obligatory.
But nevertheless, can you give me advise, how to build dynamic and static libs - in case this procedure differs from the documentation?

Thanks

mw

I have a library that depends on IPP which I compile into both a static and dynamic library (32 and 64 bit versions, and also sequential and OpenMP threaded versions of each), so it is possible. However, my library is pure unmanaged code (it sounds like you might have a mix of managed and unmanaged). When I want to use portions of my unmanaged library in managed code I add a C wrapper and use DllImport.

Special instructions ... not really, I just followed the directions in the Users Manual. You might want to start by creating a new and mostly empty unmanaged library to make sure it works the way you need. You could also upload the solution for additional assistance: note that I have had very good experience with Intel Premier support which comes with the package.

Peter

Quoting - pvonkaenel

I have a library that depends on IPP which I compile into both a static and dynamic library (32 and 64 bit versions, and also sequential and OpenMP threaded versions of each), so it is possible. However, my library is pure unmanaged code (it sounds like you might have a mix of managed and unmanaged). When I want to use portions of my unmanaged library in managed code I add a C wrapper and use DllImport.

Special instructions ... not really, I just followed the directions in the Users Manual. You might want to start by creating a new and mostly empty unmanaged library to make sure it works the way you need. You could also upload the solution for additional assistance: note that I have had very good experience with Intel Premier support which comes with the package.

Peter

Ok, I'll try this the next time. The reason for this problem(s) can of course located within the managed/unmanaged mixing stuff.
A wrapper class for all functions is hard work, isn't it?

Btw: The workaround for the corrupt files was the direct include of the obj-files. This is from the MSDN.

mw

Quoting - mweissbach

Ok, I'll try this the next time. The reason for this problem(s) can of course located within the managed/unmanaged mixing stuff.
A wrapper class for all functions is hard work, isn't it?

Btw: The workaround for the corrupt files was the direct include of the obj-files. This is from the MSDN.

mw

I uploaded a small sample of a library using IPP, mixing native and managed code.

best regards

Attachments: 

AttachmentSize
Downloadapplication/zip IppLinkTest2.zip16.66 KB

Quoting - mweissbach

Ok, I'll try this the next time. The reason for this problem(s) can of course located within the managed/unmanaged mixing stuff.
A wrapper class for all functions is hard work, isn't it?

Btw: The workaround for the corrupt files was the direct include of the obj-files. This is from the MSDN.

mw

Writing the C API calls in the unmanaged library and then creating the managed class that uses them (through DllImport) is not very hard, it's just tedious. I also find that this is a fairly clean way isolate unsafe code: write unsafe pixel type operations in C/C++ in the unmanaged lirbary and use it from a safe managed application.

Peter

Quoting - pvonkaenel

Writing the C API calls in the unmanaged library and then creating the managed class that uses them (through DllImport) is not very hard, it's just tedious. I also find that this is a fairly clean way isolate unsafe code: write unsafe pixel type operations in C/C++ in the unmanaged lirbary and use it from a safe managed application.

Using DllImport can be tricky (esp. if you want to call native functions having structs as arguments, marshaling those properly is not too obvious IMHO)...
This is why I add a "middle" layer (cf. my sample) with a managed c++ dll (which makes interaction between fully managed and native code easier)...

Quoting - elhefe38

Using DllImport can be tricky (esp. if you want to call native functions having structs as arguments, marshaling those properly is not too obvious IMHO)...
This is why I add a "middle" layer (cf. my sample) with a managed c++ dll (which makes interaction between fully managed and native code easier)...

That's pretty neat, thanks for the example. I had never attempted that approach since I have only used C# for .NET development, but now I finally see a good use for C++ .NET. However, I do havea few questions/concerns:

1) I see that in the unmanaged DLL tou link with /MT (just as I tend to do), but the managed wrapper DLL must link with /MD. Aren't there potential conflicts with this?

2) You're linking with the static libopmp5mt.lib instead of DLL stub libiomp5md.lib. Two modules in the same application using their own copy of OpenMP can cause problems with straight unmanaged code. Is there a special reason for using it here?

3) When I write the C# wrappers around my unmanaged C API calls I try to avoid cases where marsheling is necessary, but from time to time you just have to do it. How does it happen in your mixed library? Does it all just happen under the hood, or do you need to do anything special to get it to happen: I saw your use of msclr::interop::marshal_as(str). Do you need to do the same sort of thing for complex structs? How is it different from the pure managed marsheling in C#?

Thanks again,
Peter

Hello

Quoting - pvonkaenel

That's pretty neat, thanks for the example. I had never attempted that approach since I have only used C# for .NET development, but now I finally see a good use for C++ .NET. However, I do havea few questions/concerns:

1) I see that in the unmanaged DLL tou link with /MT (just as I tend to do), but the managed wrapper DLL must link with /MD. Aren't there potential conflicts with this?

2) You're linking with the static libopmp5mt.lib instead of DLL stub libiomp5md.lib. Two modules in the same application using their own copy of OpenMP can cause problems with straight unmanaged code. Is there a special reason for using it here?

3) When I write the C# wrappers around my unmanaged C API calls I try to avoid cases where marsheling is necessary, but from time to time you just have to do it. How does it happen in your mixed library? Does it all just happen under the hood, or do you need to do anything special to get it to happen: I saw your use of msclr::interop::marshal_as(str). Do you need to do the same sort of thing for complex structs? How is it different from the pure managed marsheling in C#?

Thanks for your comments. The archive I uploaded was in fact a small test case for Intel support exposing a linking issue in some cases with IPP 6.0.1

1- This combination seems to work. I had to tweak those settings to be able to statically link IPP routines (with dispatching and threading). I have not found any other problems with this so far. What kind of problems were you thinking of ?

2- Errr... this is the only option I have (the other versions are distributed with Intel's compiler for which I do not have a license... yet ;). Again, this seems to cause no particular problem.

3- The MSDN doc says you can extend the marshal_as class to perform dirty little marshal tricks ;) but I have never used it (never needed to). Before this class was introduced, I had to resort to System::Runtime::InteropServices::Marshal class, to convert String^ to char* and so on, which was not really intuitive to use. Of course, if you know the pinvoke.net web site, you will manage to solve most of your marshaling cases directly for Win32 API...

Best regards

Quoting - elhefe38

Thanks for your comments. The archive I uploaded was in fact a small test case for Intel support exposing a linking issue in some cases with IPP 6.0.1

1- This combination seems to work. I had to tweak those settings to be able to statically link IPP routines (with dispatching and threading). I have not found any other problems with this so far. What kind of problems were you thinking of ?

2- Errr... this is the only option I have (the other versions are distributed with Intel's compiler for which I do not have a license... yet ;). Again, this seems to cause no particular problem.

3- The MSDN doc says you can extend the marshal_as class to perform dirty little marshal tricks ;) but I have never used it (never needed to). Before this class was introduced, I had to resort to System::Runtime::InteropServices::Marshal class, to convert String^ to char* and so on, which was not really intuitive to use. Of course, if you know the pinvoke.net web site, you will manage to solve most of your marshaling cases directly for Win32 API...

Best regards

1) If you have an application linking with 2 DLLs one which uses /MT code generation and one with /MD code generation you end up with two copies of the C run-time (which can potentially be different versions). Some things passed across modules can be a problem. For example, if one DLL allocates memory and the other tries to deallocate it, it can crash the program. This is a bit of a contrived case, but you get the idea. I try to either always use /MT or always use /MD, but avoid mixing them. I think /MD is safer, but I like to use /MT to reduce external dependencies.

2) I was using 2 DLLs recently each of which depended on the static version of OpenMP. My application worked as long as it only used one of the DLLs, but as soon as both were used the OpenMP initialization (which seems to have been duplicated) cased the application to crash. I would highly recommend getting access to the libiomp5md version unless you can get everything statically linked into a single module. If you're mising managed with unmanaged code, static linking might not even be an option.

3) Thanks for the pointer, I'll have to look into doing that. It does sound easier than using DllImport when marsheling is required.

Peter

Quoting - pvonkaenel

1) If you have an application linking with 2 DLLs one which uses /MT code generation and one with /MD code generation you end up with two copies of the C run-time (which can potentially be different versions). Some things passed across modules can be a problem. For example, if one DLL allocates memory and the other tries to deallocate it, it can crash the program. This is a bit of a contrived case, but you get the idea. I try to either always use /MT or always use /MD, but avoid mixing them. I think /MD is safer, but I like to use /MT to reduce external dependencies.

2) I was using 2 DLLs recently each of which depended on the static version of OpenMP. My application worked as long as it only used one of the DLLs, but as soon as both were used the OpenMP initialization (which seems to have been duplicated) cased the application to crash. I would highly recommend getting access to the libiomp5md version unless you can get everything statically linked into a single module. If you're mising managed with unmanaged code, static linking might not even be an option.

3) Thanks for the pointer, I'll have to look into doing that. It does sound easier than using DllImport when marsheling is required.

Peter

1) By design I avoid allocating in a module and deallocating in another one. But thanks for the tip, I'll keep that in mind.

2) Having only IPP installed I have no other choice at the moment

Best regards
Nicolas

Leave a Comment

Please sign in to add a comment. Not a member? Join today