unresolved intel_fast_memcpy

[martymike]

This project has a C main, with Fortran code build into a static library and included.

The link step includes libifcoremd.lib and libmmd.lib

I've searched the dll's that are included with my IVF 9.1 installation and have not been able to find one that exports this symbol.

I have several projects similarly structured - only this one gets this error, and only the release build. Reducing the optimization the reference, also.

[TimP]

If you have C code compiled against which comes with ICL, that would replace any memcpy() function you employed by this function. Then, most likely, you would want to use ICL to drive the link, adding the appropriate ifort libraries. You would have to give us more details to permit more meaningful response.
intel_fast_memcpy() looks for several families of Intel CPUs and optimizes memcpy() for specific CPU types, including the use of SSE vector instructions where appropriate. In some situations, it can optimize data moves which are not optimized by ifort. With all the extra run-time analysis, it pays off only for long string moves.

[martymike]

Hmmm. I posted a reply to this, but it's not here. Let's try again:

I don't know what ICL is; Intel C for Linux, perhaps?

I'm running on Windows, using IVF 9.1 and MS VC/C++ 2005.net. The unresolved reference is from a Fortran routine. This is the message:

convertrawf.lib(convertrawapi.obj) : error LNK2019: unresolved external symbol __intel_fast_memcpy referenced in function _CONVERTRAW._CONVERTRAWFILE

Convertrawapi.obj comes from convertrawapi.for, a Fortran file which contains a single external subroutine named CONVERTRAW. There are several CONTAINed subroutines, one of which is CONVERTRAWFILE. The longest string referenced in that routine is declared at a length of 260.

My question, however, is not so much as to whether the compiler should have generated the reference to the routine in question - I'm willing to trust it in that regard - but in where in the world does that routine reside so that I can complete the link?

[TimP]

OK, I wasn't aware that ifort would substitute fast_memcpy() calls directly, for long string copies. As this is an Intel C library function, you would expect it to come from one of the libirc*.lib For 64-bit Windows, I think there is only one of them. For 32-bit, there are both thread-safe and non-thread-safe versions. You could confirm this by e.g.
cd to the lib directory of your ifort installation
dumpbin /symbols libirc* | grep fast_memcpy
Also, you could write a simple ifort application with such usage and
ifort -# yourstrcpy.f
would show you which libraries ifort has to search.

[Steven_L_Intel1]

Do this. In the Fortran library project, right click on the project, select Properties. On the Fortran > Libraries page, change the value of "Disable default library search rules" to "No (inherit from project)". When you create a Fortran static library project, this property is set to Yes, which makes sense if you are linking with other Fortran code but not if linking with C code.

Now you'll get all the appropriate libraries pulled in, as long as you have added the path to the Intel Fortran LIB folder under Tools > Options> Projects > VC++ Directories > Library Files.