Log/Pow conflict with ICC16 Update 2 + Visual C++ 2015 Update 1 on Win32

[Rolland__Jean-Baptis]

Dear Intel Compiler Experts,

Even if the Update 2 fixed most of the issue, there is still one important problem I'm not able to find out how to fix it.

As usual, I have a project composed on two static libraries, one compiled with ICC and the other one with the Microsoft VC++ Compiler. Both are using the math function log/pow. When I build the project on Win64, everything is linking correctly. Unfortunately it is not the case for Win32...

3>libucrt.lib(pow.obj) : error LNK2005: _pow already defined in libmmt.lib(pow_iface.obj)
3>libucrt.lib(pow.obj) : error LNK2005: __CIpow already defined in libmmt.lib(pow_iface.obj)
3>libucrt.lib(log.obj) : error LNK2005: _log already defined in libmmt.lib(log_iface.obj)
3>libucrt.lib(log.obj) : error LNK2005: __CIlog already defined in libmmt.lib(log_iface.obj)

Of course, if I exclude libucrt or libmmt from the compilation I have some missing symbols.

This error seems analog to http://siliconandlithium.blogspot.de/2014/04/intel-and-microsoft-compiler-linker.html but in my case there is no such floating point representation difference or whatever.

Is it a configuration problem from my side, or is there a known conflict between libmmt and libucrt that will be solved in further updates?

Thanks in advance!

Best Regards,

JbR

[KitturGanesh]

Hi Jean-Baptiste,
Firstly, our apologies that there's a delay in a response (this can happen rarely :-().
What I need from you is a reproducer so I can investigate and file the issue with our developers as I am not able to reproduce the issue. It is known that we provide same symbols as MS does and this issue needs investigation. Attaching a test reproducer helps me to file and see if I can get a workaround to avoid conflict etc.

Again, thanks for your patience and look forward to a test reproducer.

Regards,
Kittur

[Wai_P_]

We are having the same problem. Is there any updates on this thread?

In a similar fashion, we are using MSVC compiler 32bit vs2015 linking on a lib that is built with ICC and has a dependency on libmmt.lib.

regards

Wai

NB problem goes away with an ICC build.

[Rolland__Jean-Baptis]

Hi Wai,

Unfortunately, we still have the issue with the last Update 3 of Visual C++ 2015 as well. A possible workaround that is unfortunately not acceptable for us is to ignore multiple definitions by using the following flag: https://msdn.microsoft.com/en-us/library/70abkas3.aspx

Force File Output: Multiply Defined Symbol Only

I hope this answer you.

Best Regards,

JbR

[Wai_P_]

It's ok with ICC build and so we will use that for now.

[Rolland__Jean-Baptis]

Dear All,

Just to keep you updated, the final solution is actually quiet simple.

The linker should link to libucrt.lib before libmmt.lib.

In consequence it is possible to add this in the project settings at Linker > Input > Additional Dependencies, make sure that "libucrt.lib" is linked before "libmmt.lib".

Everything is now working on my side without the Force File Output: Multiply Defined Symbol Only setting.

Best Regards,

JbR

[Nikita_A_Intel]

Linking with libucrt.lib before libmmt.lib you are probably forcing pow() function from libucrt.lib. I don't have your objects, so it is hard to judge why the conflict is not resolved gracefully by the linker. From your original description I'd suspect that your static library compiled with VC++ is pulling libucrt first.

If for some reason you prefer to be able to use pow() from libmmt.lib, then I would suggest you build your project (both libraries) with -Zl which will remove the dependencies on default libraries in your objects. Then you can play with the link order of the libraries in the final link line. It may prove to be more complicated than your current solution though, because depending on the way you invoke the linker you may end up manually listing all the libraries your application needs.

Thanks,
Nikita

[Papaioannou__George]

There will always be a problem with mixing code generated against different libcXX versions even when using the same compiler but as you can see from above both are generated using the 'mt' version so all should be fine. The actual solution is due to the implementation of each of these clashing functions. Above the example was the log10 function which is only clashing because it is being used in different ways that can not be resolved between the Intel and Microsoft compiler.

The culprit is a setting called "FloatingPointModel". If building through Visual Studio then this setting can be found under "C/C++->Code Generation" in the project properties.

The solution is simply making sure that all input libs are compiled using the same setting for the floating point model. This rules out using Intels "Fast2" option as this is never available on Microsoft's so it will always cause problems. But apart from that making sure they are all the same value (or not setting any value) should make this rather rare and frustrating bug go away.

Read the full article at 

https://siliconandlithium.blogspot.gr/2014/04/intel-and-microsoft-compiler-linker.html?showComment=1520792193712#c7561396434258211954