I am just switching from VC++ (Visual Studio 2008) to Intel C++ (2011, update6) and have the following compiling error:
1>ipo_51045obj.obj : error LNK2001: unresolved external symbol ___intel_sse2_strncmp
1>ipo_51045obj.obj : error LNK2001: unresolved external symbol ___intel_sse2_strcpy
1>ipo_51045obj.obj : error LNK2001: unresolved external symbol ___intel_sse2_strncat
1>ipo_51045obj.obj : error LNK2001: unresolved external symbol ___intel_sse2_strcat
The code compiles well in VC++.
I removed all 3rd party solvers, leaving only the MKL_pardiso and MKL_dss in the code. It can then compile & link but I see no executable files produced. However it all works fine if I just switch to VC++ option.
Could you please tell me what could be the issue with this?
Many thanks in advance & regards
Sorry, the libintlc library is only on Linux - my confusion.
Can you do a dumpbin /symbols libirc.lib on your libirc library and verify that those symbols are defined there? They are on my installation. I suspect you may be linking in an older version of the runtime somehow.
Why the other project is linking but not creating an executable is odd. I would check and make sure the executable is being output where you expect. You may want to do a drive search to see if the executable is being placed somewhere else. Alternatively, you may be missing a compiler or linker error somewhere. Read over the generated BuildLog by Visual Studio and see if that doesn't reveal something.
Hi Brandon & Sergey,
Thanks a lot. I tried all your suggestions and things worked in the end. The project that did not link (with the above errors) finally did and produced .exe file after I dragged (using mouse) the two library files into the project window. Before I added link to the folder contaning these library files, as I did successfully for all MKL library files, but it did not work. What is wrong with that?
The other project that did not produce .exe file still did not work. I could not find the exe file any where in my computer. There is also no error (but few warnings) that I saw in Buildlog file.
Anyway, at least it works now. If you could point out the issues then that would help me a lot when working with VS and Intell C++ compiler.
Many thanks in advance.
Thank you. I tried what you'd suggested but it did not work. I still have no idea.
It just works when I drag and drop those library files in the project. This is what I usually do when having to link with an external library. I'll try to figure out why.
The compiler is already effectively adding this pragma comment for the Intel libraries in question, so he'd still likely get linker errors regardless. Using /nodefaultlib on the linker line would remove those pragma comments (although you can use /nodefaultlib:<library> for specific libraries, but since Giang would be using the same library names, his pragma comments would be removed).
Giang, would you be willing to send us your solution and source so we can see the problem on our side? If that is not doable, perhaps just the .vcproj and .icproj files and the BuildLogs might reveal something to us.
Typically, the Intel library path is set from Tools->Options->Intel Composer XE->C++->Compilers, so you should check those settings and ensure they're correct.
For the project that's not emitting an executable, the only thing I can think of is that perhaps you have a Static Analysis setting in there. The compiler option for that is something along the lines of /Qdiag-enable:scN where N is a number. Static Analysis does static error checking across modules and does not create binaries.
Thank you. I sent you the files.
I tried your option: "Typically, the Intel library path is set from Tools->Options->Intel Composer XE->C++->Compilers, so you should check those settings and ensure they're correct" but it did not work on my computer.
Looking at the Buildlog you sent me, I see two different LIBPATH settings with different compiler paths in them, like so:
/LIBPATH:"C:\Program Files\Intel\Composer XE 2011 SP1\compiler\lib\ia32"
(/LIBPATH:"C:\Program Files\Intel\Composer XE 2011 SP1\compiler\lib\ia32" gets repeated again as well, but that should be harmless)
I strongly suspect that the first path with 11.1 libraries is getting picked up first and causing your linker problems. Can you find out where that LIBPATH setting is originating from and remove it? This way only the 2011 SP1 directory with the more up to date compiler runtime libraries will be linked in.
Same library names, but different library versions. The Composer XE 2011 libraries are more up to date and should be used. They are backwards compatible with code generated by older compilers, so you only need the latest.
Or are you saying that you diff'd the libraries and they are bit-wise the same? That would mean something is wrong. The library contents do change over time - they get built with newer compilers for one thing even if nothing else changed. But a linker error like Giang described is definitely feasible if you're using a newer compiler generating code that calls library functions with an older version of the library that doesn't have those definitions.