undefined reference to `__intel_new_feature_proc_init' and _intel_fast_memmove

[Shaoxin_P_]

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!

[TimP]

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_]

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_]

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_C_Intel]

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.

[Martin_D_1]

I'm encountering a similar problem after updating to the newest Fortran compiler (14.0.2) on Ubuntu 12.04. The error message is the following

ipo: warning #11021: unresolved __intel_new_feature_proc_init
        Referenced in /opt/intel/composer_xe_2013_sp1.2.144/compiler/lib/intel64/for_main.o
ipo: warning #11021: unresolved _intel_fast_memmove
        Referenced in libifcoremt.a(for_f90str.o)
        Referenced in libifcoremt.a(for_90_trim.o)
        Referenced in libifcoremt.a(for_init.o)
        Referenced in libifcoremt.a(for_rseq_fmt.o)
        Referenced in libifcoremt.a(for_backspace.o)
        Referenced in libifcoremt.a(for_90_adjust.o)
        Referenced in libifcoremt.a(for_get.o)
ipo: remark #11000: performing multi-file optimizations
ipo-1: remark #11006: generating object file /tmp/ipo_ifortm6YPTt1.o
ipo-3: remark #11006: generating object file /tmp/ipo_ifortm6YPTt3.o
ipo-2: remark #11006: generating object file /tmp/ipo_ifortm6YPTt2.o
ipo-4: remark #11006: generating object file /tmp/ipo_ifortm6YPTt4.o
[...]
/opt/intel/composer_xe_2013_sp1.2.144/compiler/lib/intel64/for_main.o: In function `main':
/export/users/nbtester/efi2linux_nightly/branch-14_0/20140121_010000/libdev/frtl/src/libfor/for_main.c:(.text+0x31): undefined reference to `__intel_new_feature_proc_init'
/tmp/ipo_ifortm6YPTt1.o: In function `damask_spectral_driver':
/nethome/storage/raid4/m.diehl/DAMASK/code/DAMASK_spectral_driver.f90:11: undefined reference to `__intel_new_feature_proc_init'
/nethome/storage/raid4/m.diehl/DAMASK/code/DAMASK_spectral_driver.f90:153: undefined reference to `_intel_fast_memmove'
/nethome/storage/raid4/m.diehl/DAMASK/code/DAMASK_spectral_driver.f90:153: undefined reference to `_intel_fast_memmove'
/nethome/storage/raid4/m.diehl/DAMASK/code/DAMASK_spectral_driver.f90:179: undefined reference to `_intel_fast_memmove'
/nethome/storage/raid4/m.diehl/DAMASK/code/DAMASK_spectral_driver.f90:179: undefined reference to `_intel_fast_memmove'
/nethome/storage/raid4/m.diehl/DAMASK/code/DAMASK_spectral_driver.f90:235: undefined reference to `_intel_fast_memmove'
/tmp/ipo_ifortm6YPTt1.o:/nethome/storage/raid4/m.diehl/DAMASK/code/DAMASK_spectral_driver.f90:235: more undefined references to `_intel_fast_memmove' follow
make: *** [DAMASK_spectral.exe] Error 1

Please note the strange reference to /export/users/.... This directory does not exist on the system.

The linker command (calling ifort with -v) reveals a mixture of dynamic and static linking:

1 /opt/intel/composer_xe_2013_sp1.2.144/bin/intel64/fortcom
2 [...]
3 "CPFEM.o" "DAMASK_spectral_utilities.o" "DAMASK_spectral_solverBasic.o"
4 "-lfftw3" "-lfftw3_threads" "-lpthread" "-liomp5" "-lacml" "-rpath" "/usr/local/lib" "-rpath" "/nethome/m.diehl/acml/ifort64/lib"
5 "-Bdynamic" "-Bstatic" "-lifport" "-lifcoremt" "-limf" "-lsvml" "-Bdynamic" "-lm" "-Bstatic" "-lipgo" "-Bdynamic" "-liomp5" "-Bstatic" "-lirc" "-Bdynamic" "-lpthread" "-Bstatic" "-lsvml" "-Bdynamic" "-lc" "-lgcc" "-lgcc_s" "-Bstatic" "-lirc_s" "-Bdynamic" "-ldl" "-lc" "/usr/lib/gcc/x86_64-linux-gnu/4.6/crtend.o"

where many paths are left out that seem uninteresting to me. Line 3 shows the my compiled Fortran files, line 4 my explicitly added linker options and line 5 the options added by the linker with may changes between dynamic and static linking.

Adding -shared-intel helps to compile, the linker command looks then similar, but in line 5:

"-lifport" "-lifcoremt" "-limf" "-lsvml" "-lm" "-lipgo" "-liomp5" "-lintlc" "-lpthread" "-lsvml" "-lc" "-lgcc" "-lgcc_s" "-lirc_s" "-ldl" "-lc" "/usr/lib/gcc/x86_64-linux-gnu/4.6/crtend.o"

only dynamic linking options are given. It also helps to link explicitly agains libifcoremt and libirc.

Is there a way to figure out if my libifcoremt.a has the wrong version to check if static linking would be ok if the file is the correct one?

[Steven_L_Intel1]

Replace -lirc with -lintlc

We changed the name of libirc a couple of releases ago to avoid a conflict with a different library that had the same name.

The /export/users is from the system where libfor was built.