Linker error LNK2001: unresolved symbol "void __cdecl terminate(void)"

[Andre_N_]

Hi

I'm currently trying to compile the Ogre3D library with Intel Compiler 16.0 and Visual Studio 2015.
Compiler Version: Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.0.110 Build 20150815

Yesterday I compiled the whole library with Visual Studio 2015 compiler without any issues, but now with Intel Compiler I get linking errors, since it cannot find the symbol ""void __cdecl terminate(void)" (?terminate@@YAXXZ)" after compiling.

By searching in the internet I saw, that this symbol should be inside the msvcrt.lib from Microsoft, however I found also this post, where someone has the same issues with compiling Qt, also with Intel Compiler 16.0:
https://bugreports.qt.io/browse/QTBUG-48039

I tried to add msvcrtd.lib manually to the linker command, but this did not solve the issue.
Does anyone know anything about this? Is this a toolchain error or just a configuration err?

Best regards,
André

[Shenghong_G_Intel]

Hi Andre,

I think the issue mentioned in QT bug report is clear. "The problem is that the function does not exist with decorated name. Up until MSVC 2013, it did exist in msvcrt(d).dll, but in 2015 it does not. It only exists in undecorated name." So, linking to msvcrt.dll manually will not workaround the issue.

It seems like no easy workaround. I think fixing the QT test case should also fix your issue. There are lots of changes in MSVC2015 runtime, which makes such compatibility issues from Intel compiler.

Thanks,

Shenghong

[Andre_N_]

Hi Shenghong

Thanks for your reply. I don't know if it is really clear, since I was not able to reproduce this issue with the reduced testcase from the Qt-Forum. So even when the issue from the Qt Forum fits exactly to my issue, I was not able to verify if the statements in this forum are correct or not.

Did your team get any error report like this before?
If so, have you reproduced it internally?
If not, how to proceed here?

Which conditions must be fulfilled to automatically generate a reference to the "terminate" function during compiling?
When I call this function directly in a short test program, then everything is fine during linking. However the Ogre3D code does not call this function directly, it seems, that the compiler generates these references.
So when I know which condition must be fulfilled, I can try to reproduce it with a small test program. This would make the job of your team easier, I guess.

I can also give you the object files and source files where the error happens. But be aware: This is a big and complex library project and you cannot compile it out of the box without fulfilling a ton of external dependencies.

Do you have any further idea what I can try to workaround this issue?

Best regards,
André

[Shenghong_G_Intel · Accepted solution]

Hi Andre,

It is interesting that you cannot reproduce the Qt issue. I guess you are building on command line? When I create a default VS project, and copy the code in it, it can be reproduced.

I've also tried on command line just now, and it cannot be reproduced with default options. And I've figured out the condition to reproduce it:

>call "C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.0.110\windows\bin\compilervars.bat" ia32 vs2015
> icl test.cpp /Qipo /EHsc /nologo

/Qipo and /EHsc are needed to reproduce it! You may check your build options in Ogre3D, and see whether it can work by removing one of these options.

But still, to clarify this issue, it is kind of common issue which may also affect other cases, other condition may also cause compiler generating function call to "terminal". The root cause of the issue is, in VS2015, there are some name mangling changes and causing issues only for vs2015.

Did your team get any error report like this before?
If so, have you reproduced it internally?
If not, how to proceed here?

>> I've already submitted the QT issue to dev team to fix and give a higher priority as it also affect Ogre3D. And the good news is, there was a known issue for this and already fixed internally.

Let me know if you still have concerns. 

Thanks,

Shenghong

[Andre_N_]

Hi Shanghong

Thanks for sharing this information. Yes I compiled on command line without any specific options. When I add the /EHsc option the sample from the Qt forum really shows the same behaviour.
However the /EHsc option is necessary for compiling the Ogre3D library, compiling without will lead to many link errors that are specific to exception handling in general. So I think the only chance for me is to wait until your team found a solution.

It's good to hear, that this issue is still in work at your team. Do you have an idea what the ETA of a patch could be?

It seems that the Intel Compiler has several issues at the moment with the MSVC2015 front end, I guess MSVC2013 is more stable to far. When I would have a choice I would use the GCC front end for Intel Compiler also on Windows, but Intel is not supporting this... to bad, especially since for Linux it works so good.

I will wait for a patch.

Have a nice day and thanks for your assistance,
André
 

[Shenghong_G_Intel]

Hi Andre, Do you have an idea what the ETA of a patch could be? >> If the issue is confirmed to be fixed in mainline (dev tried with dev version and it cannot be reproduced), it should be part of the next update release. I do not have the date of the release, but according to experiences, it is usually in 2 or 3 months. You are correct, there are some issues with VS2015 because VS2015 seems to have some changes in its runtime library. Regarding GCC front end on windows, it is possible to use MinGW or Cygwin, but it is not official supported, you may search around and there are some articles mentioning about this. Thanks, Shenghong

[Andre_N_]

Hi Shenghong

Thanks, I will just wait until the patch is available. Hopefully it will be soon :)

Regarding MinGW and Intel Compiler: I searched a lot of times for answers to this topic. I searched in this Forum and also outside in the Internet, but I did not get any useful answer or approach to use the MinGW Front End for Intel Compiler on Windows.

The MinGW compiler itself is quite buggy and there is only a poor support for fixing known issues. However having the same Compiler Front End for Windows and Linux is a very big advantage, when you want to implement applications that are platform independent. That's why I really would like to use the Intel Compiler with MinGW front end on Windows, because this would give me the advantage of platform compatibility combined with a good working high performance compiler.

So when you know any approach, even when this is not an official solution, to archive this, I will really give it a try. But so far the only answer I found was: When you want to use Intel Compiler on Windows, you are forced to use the Microsoft Toolchain. 

Best regards,
André

[TimP]

cygwin is more oriented than MinGW toward windows vs. linux platform independence.  It seems unlikely (to me) that a g++ front end would solve problems associated with differences between MSVC++ and ICL front ends.

You're probably aware that VS2015 tends to break ICL when upgraded in place, due to incomplete transition to new Windows Kits folders.  You will see old Windows Kit paths in the LIB and INCLUDE environment even though there are new folders which contain the files which are now missing from the old ones.  The solution which was proposed to me on this forum was to remove and reinstall VS2015 and ICL entirely when an upgrade breaks it.