undefined reference to `__intel_new_feature_proc_init' and _intel_fast_memmove

undefined reference to `__intel_new_feature_proc_init' and _intel_fast_memmove

Shaoxin P.'s picture

Hi All,

While linking with ifort, I met the following error:

dd_main_io.o: In function `main':
dd_main_io.cc:(.text+0x2d): undefined reference to `__intel_new_feature_proc_init'
/opt/intel/composerxe/lib/intel64/libifcoremt.a(for_init.o): In function `for__signal_handler':
for_init.c:(.text+0x8ce): undefined reference to `_intel_fast_memmove'
for_init.c:(.text+0x8e7): undefined reference to `_intel_fast_memmove'
for_init.c:(.text+0x900): undefined reference to `_intel_fast_memmove'
for_init.c:(.text+0x919): undefined reference to `_intel_fast_memmove'
for_init.c:(.text+0x932): undefined reference to `_intel_fast_memmove'
/opt/intel/composerxe/lib/intel64/libifcoremt.a(for_init.o):for_init.c:(.text+0x94e): more undefined references to `_intel_fast_memmove' followic

My project is a mix of c and fortran files. I used icpc and ifort to compile them seperately to get .o files, and I use the following command line to link:

ifort -O2 -fopenmp -o test (many_cpp).o (fortran).o -L/user_library_path -L/opt/intel/composerxe/lib/intel64 -nofor-main -l(many_user_library) -lirc -lifport -lifcoremt -lifcore -lsvml -lirc

I am almost desperate now. Any suggestion is appreciated. Thank you very much!

5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
Tim Prince's picture

This doesn't entirely make sense, as the .so version of libifcore and the other ifort and icc libraries would take precedence over the .a libraries, unless you specified a static link option.  With .so libraries, the order of linking wouldn't matter, and all the libraries would be included by default when you set up the environment variables as sourceing the compilervars script would do.

test of course is an unsatisfactory name for a user executable, in view of possible conflicts with shell built-ins.

If some of those libraries were built with static linking against the compiler libraries, that could be a problem.  So could using an older version of the compiler to link than the one used to build some .o files.

Shaoxin P.'s picture

Quote:

TimP (Intel) wrote:

This doesn't entirely make sense, as the .so version of libifcore and the other ifort and icc libraries would take precedence over the .a libraries, unless you specified a static link option.  With .so libraries, the order of linking wouldn't matter, and all the libraries would be included by default when you set up the environment variables as sourceing the compilervars script would do.

test of course is an unsatisfactory name for a user executable, in view of possible conflicts with shell built-ins.

If some of those libraries were built with static linking against the compiler libraries, that could be a problem.  So could using an older version of the compiler to link than the one used to build some .o files.

 

Hi Tim,

 

Thanks for the reply!

The source <install path>/compilervars intel64 is executed. The name "test" is just what I put here for simplicity.

You are right about the libraries. Some libraries are indeed static libraries, compiled with gnu c/g++. 

I also tried to put a -static-intel tag to the linker ifort. The same error. Would you please provide further instructions to try? I am totally ignorant about compiler stuff..

Thank you!

 

Regards,

Sam

Xin F.'s picture

Hi~~

I also encountered this problem when compiling fortran and C files. So I want to know have you solved it yet ?

Thanks.

Xin

Martyn Corden (Intel)'s picture

Which compiler version(s) are you using?   (use ifort -V  and icc -V to find out).

I believe the message may be caused by mixing objects built with different compiler versions. The __intel_new_feature_proc_init entry point is only in recent compiler libraries; if you have code built with a recent compiler, but are linking to older run-time libraries, you might encounter such a problem.

Best is to build everything with the same compiler version; if this isn't an option, then at least use the most recent compiler version for linking. The original post had a long string of libraries on the ifort command line, including some that make no sense together (ifcoremt and ifcore). There's no need for this; better to let the ifort driver choose which libraries to link, and let it take them from the same installation as the compiler (so don't specify the compiler library path with -L). Use the switch -cxxlib to ask the driver to link also to the standard C++ libraries, if needed. It is better to use ifort rather than icc or icpc for linking mixed language applications, because ifort can link the libraries for all 3 languages, whereas the other drivers do not know how to link Fortran libraries. This is summarized in the Fortran User's Guide in the section "Compiling and Linking Intel® Fortran/C Programs" under Mixed Language Programming.

Login to leave a comment.