LNK2005 error in VS2015

[Frederic_Vanmol]

Hello,

I'm upgrading to the latest version of IPP, v2017 update 1.

When I build my C++ dll project in VS2015 in 32bit I get these link errors:
1>ippsmt.lib(psexpca_px---ippsExpOne.obj) : error LNK2005: ___libm_exp_hi_table_64 already defined in libmmt.lib(exp_table.obj)
1>ippsmt.lib(psexpca_px---ippsExpOne.obj) : error LNK2005: ___libm_exp_mi_table_64 already defined in libmmt.lib(exp_table.obj)
1>ippsmt.lib(psexpca_px---ippsExpOne.obj) : error LNK2005: ___libm_exp_lo_table_64 already defined in libmmt.lib(exp_table.obj)
1>ippsmt.lib(psexpca_px---ippsExpOne.obj) : error LNK2005: ___libm_exp_table_128 already defined in libmmt.lib(exp_table.obj)

It builds without these errors in 64bit.

This seems to be because of two reasons:
1. I use ippsmt.lib
2. the "Runtime Library" option for the project is set to "Multi-threaded (/MT)"

When I switch the runtime library option to "Multi-threaded DLL (/MD)", the project builds fine. However, this means my dll then requires msvcrt110.dll, which I don't want.

I have the impression that the 32bit ippsmt.lib was built with the /MD option instead of /MT. Could this be the problem? Or am I doing something wrong?

Regards,
Frederic Vanmol

[Zhen_Z_Intel]

Dear customer,

Are you using ipp exp function? Seems your program built with Intel compiler, I could not reproduce your problem whatever I use IPP single/multi-thread static lib (ippsmt), could you send VS project with your test case and tell me which functions you are using. Thanks.

Best regards,
Fiona

[Frederic_Vanmol]

This a dll that makes the functions available to our program (written in Delphi, so it can't use IPP directly). It does export some ippsExp functions, but those don't seem to influence it.

The dll is built with the Intel Compiler (2013). With the VC++ 2015 compiler I get a LNK1181 error "cannot open input file 'ippccmt.lib" (which is in the library search paths, as far as I can tell).

It seems that it's related to the Antigrain code that's also in the dll. If I remove that, the dll builds fine. I have no idea at this point why it would cause that (it doesn't seem to link to any libs so far), but it's a starting point.

If you're still interested in looking at the project, is there some way I can send it to you in private?

Regards,
Frederic

[Adriaan_van_Os]

Why couldn't your Delphi program use IPP directly ? ? I think <http://adriaan.biz/intel/ipp.pas.zip> would compile with minor modifications.

Regards,

Adriaan van Os

[Frederic_Vanmol]

Adriaan van Os wrote:
Why couldn't your Delphi program use IPP directly ? ? I think <http://adriaan.biz/intel/ipp.pas.zip> would compile with minor modifications.

The problem is that this would rely on the actual IPP dlls. These are very big as they also include a lot of functions that we don't actually use.

Our custom dlls are 26MB (32bit) and 34MB (64bit). In contrast, the IPP redistributable dlls seem to be about 150MB (32bit) and 262MB (64bit). Granted, we probably wouldn't need all of them, but it's still a significant size increase. Even just the ippi and ipps dlls are huge compared to what we have now.

Regards,
​Frederic

[Adriaan_van_Os]

But can't you build those custom DLLs with the Intel Custom Library Tools ?

Regards,

Adriaan van Os

[Frederic_Vanmol]

Adriaan van Os wrote:
But can't you build those custom DLLs with the Intel Custom Library Tools ?

Sure, but it would require changing some other code because the custom dlls also have some other code (Antigrain).

It may be the only solution, as there seems to be some conflict between IPP and Antigrain with this new version of IPP. I'd like to at least find out what the problem is first, however.

Regards,
Frederic

[Frederic_Vanmol]

It looks like Antigrain uses the pow() function from math.h. When I remove that use, there are no problems building the dll.

I don't have any idea why this would lead to linker errors, however.

[Igor_A_Intel]

Hi Frederic,

This is IPP and Intel libm coexistence issue - we made IPP independent from libm and embedded several libm functions, but data tables used by these 2 libraries have the same names. We have already fixed this issue in IPP 2017 update #2 (renamed tables). Therefore the workaround for 2017 upd#1 is to avoid use of IPP and libm in 1 application or use linker switches such as /FORCE:MULTIPLE (Visual Studio) and --allow-multiple-definition (gcc).

​regards, Igor.

[Frederic_Vanmol]

Hello Igor,

Thanks for the explanation. I've made sure my custom dll doesn't use libmmt.lib for now, but I'll also take a look at the options you mention. I look forward to update 2.

Regards,
Frederic