/NODEFAULTILB:libmmd.lib results in unresolved external symbols

[kevin_watters]

I want my app not to depend on libmmd.dll, especially since the only functions that it is depending on it for at the moment are sin, cos, and pow.

Following advice I saw elsewhere on this forum, I tried adding /NODEFAULTLIB:libmmd.lib to my Visual Studio project's linker options.

That results in unresolved external symbols for sin/cos and pow, however:

2>ipo_85526obj.obj : error LNK2019: unresolved external symbol ___libm_sse2_sincos referenced in function _cmath_rect
2>ipo_85526obj.obj : error LNK2019: unresolved external symbol _pow.J referenced in function _math_pow

Is there some other way I can compile my app with icl, but have it not depend on libmmd?

[JenniferJ]

If you do not want to distribute the dynamic DLL, you should link with the static lib "libmmt.lib".

Jennifer

[kevin_watters]

Quoting - Jennifer Jiang (Intel)

If you do not want to distribute the dynamic DLL, you should link with the static lib "libmmt.lib".

Jennifer

We did end up linking statically against libmmt.lib. Unfortunately our executable size increased by 500kb, which seems way too much, considering the only 3 or so functions that were being linked to dynamically.

What I'm really looking for is a way to pull those math functions above (sin, cos, pow) not from Intel's intrinsics libraries, but from the MSVC CRT, like cl.exe would do normally. No new dependency, no massive code size increase. I played around with options related to this (use intrinsics, etc) but couldn't get this to work. Is there a way to accomplish this?

[P_A__Jimenez]

I am having the same problems as the OP about unresolved symbols when avoiding linking against libmmd.dll. I do not mind about redistributing the DLL or linking statically, but it is causing problems with some of our customers who are trying to run our software in AMD Sempron and Athlon XP CPUs. The problem is caused by libmmd.dll executing an illegal instruction on those CPUs. Is there anything I can do about it?

[TimP]

Quoting - binksoftware

I am having the same problems as the OP about unresolved symbols when avoiding linking against libmmd.dll. I do not mind about redistributing the DLL or linking statically, but it is causing problems with some of our customers who are trying to run our software in AMD Sempron and Athlon XP CPUs. The problem is caused by libmmd.dll executing an illegal instruction on those CPUs. Is there anything I can do about it?

Just to satisfy curiosity: are those CPUs reporting they support SSE2 but failing SSE2 instructions, or does the library pick SSE3 instructions? This might be further reason to request a math library which complies with the instruction set specified in the compilation.

[P_A__Jimenez]

Quoting - tim18

Just to satisfy curiosity: are those CPUs reporting they support SSE2 but failing SSE2 instructions, or does the library pick SSE3 instructions? This might be further reason to request a math library which complies with the instruction set specified in the compilation.

I got an old PC to run the test, and the CPU (AMD Athlon XP 3200+) supports up to SSE. According to WinDbg the offending instruction is a movsd xmm0, , which is, from what I found, an SSE2 instruction. However, the instruction seemed to occur somewhere in the generated code instead of libmmd.dll.

After changing some of the settings in the project I was able to compile and link the program without it trying to use libmmd. The program does not crash in the test PC anymore, but it does not make use of any newer instructions if available either.

[TimP]

Quoting - binksoftware

I got an old PC to run the test, and the CPU (AMD Athlon XP 3200+) supports up to SSE. According to WinDbg the offending instruction is a movsd xmm0, , which is, from what I found, an SSE2 instruction. However, the instruction seemed to occur somewhere in the generated code instead of libmmd.dll.

After changing some of the settings in the project I was able to compile and link the program without it trying to use libmmd. The program does not crash in the test PC anymore, but it does not make use of any newer instructions if available either.

You're right, the current Intel compilers no longer have a facility to use SSE without SSE2, so as to give full support to P-III or Athlon 32-bit. The corresponding -QxK option worked best in ICL 8.1; it was still present, but not fully reliable, in 10.1. For 11.x, you must use /QxIA32 to generate code for those CPUs, and the compiler itself will not run on those old CPUs.