intel c++ compiler return undefined reference

[Danesh_Daroui]

Hi all,

I am testing a ".so" file under Linux to link it with my code. I compile a singe C file using "icc" as below and it works fine and the code compiles correctly:

icc pardiso_unsym_complex.c -o pardiso -L "/home/dan/Downloads/" -L "/home/dan/intel/fortran/lib/intel64/" -L "/home/dan/intel/Compiler/11.1/075/mkl/lib/em64t/" -L "/home/dan/intel/Compiler/11.1/075/lib/intel64/" -lpardiso411-INTEL101-X86-64 -lifcore -liomp5 -lpthread -lguide -lgfortran -lgomp -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core

but when I just use "icpc" instead of "icc" I get many udefined referenc errors:

pardiso_unsym_complex.cpp:(.text+0x423): undefined reference to `pardisoinit(void*, int*, int*, int*, double*, int*)'
pardiso_unsym_complex.cpp:(.text+0x47f): undefined reference to `pardiso_chkmatrix_z(int*, int*, doublecomplex*, int*, int*, int*)'
pardiso_unsym_complex.cpp:(.text+0x4b6): undefined reference to `pardiso_chkvec_z(int*, int*, doublecomplex*, int*)'
pardiso_unsym_complex.cpp:(.text+0x507): undefined reference to `pardiso_printstats_z(int*, int*, doublecomplex*, int*, int*, int*, doublecomplex*, int*)'
pardiso_unsym_complex.cpp:(.text+0x5d8): undefined reference to `pardiso(void*, int*, int*, int*, int*, int*, doublecomplex*, int*, int*, int*, int*, int*, int*, doublecomplex*, doublecomplex*, int*, double*)'
pardiso_unsym_complex.cpp:(.text+0x6bf): undefined reference to `pardiso(void*, int*, int*, int*, int*, int*, doublecomplex*, int*, int*, int*, int*, int*, int*, doublecomplex*, doublecomplex*, int*, double*)'
pardiso_unsym_complex.cpp:(.text+0x79b): undefined reference to `pardiso(void*, int*, int*, int*, int*, int*, doublecomplex*, int*, int*, int*, int*, int*, int*, doublecomplex*, doublecomplex*, int*, double*)'
pardiso_unsym_complex.cpp:(.text+0x86a): undefined reference to `pardiso_chkvec_z(int*, int*, doublecomplex*, int*)'
pardiso_unsym_complex.cpp:(.text+0x9cf): undefined reference to `pardiso(void*, int*, int*, int*, int*, int*, doublecomplex*, int*, int*, int*, int*, int*, int*, doublecomplex*, doublecomplex*, int*, double*)'



what is the problem? Why "icpc" doesn't compile while "icc" works correctly? Any hint for that?

Thanks,

D.

[Danesh_Daroui]

and one more thing, even when I change the extension of the source code to ".cpp" and compile it with "icc" I again get "undefined reference" error which is normal since when files with ".cpp" is being compiled using Intel, "icpc" will automatically launched. I am wondering if I need to pass parameters in the command in an different way when "icpc" is used.

Thanks,

D.

[TimP]

It looks like you haven't included the headers to define the pardiso functions as using C linkage (no C++ mangling of the names). Also, it seems like a very bad idea to link against 3 incompatible OpenMP libraries and 2 incompatible Fortran run-time libraries in random order.

[Danesh_Daroui]

Thanks! As you mentioned, icpc mangles function names so all I needed to do was to add

extern "C"

before function headers. What did you mean about incompatible OpenMP libraries and Fortran run-time libraries in random order? Would it be efficient if I change the order or remove some libraries? Are they redundant? DO you have any suggestion?

Thanks,

D.

[TimP]

If you have functions which depend on libguide or libgomp, libiomp5 will take care of all of them. If you stay with dynamic linkage against libiomp5, it won't make a lot of difference where that library is specified in your command line, as long as it follows at least one reference to it, but it still seems preferable to list dependencies in order. You will run into trouble if you link against parts of more than one of those libraries (even if you link against multiple versions of libiomp5).
I guess it may be OK to link against libgfortran, provided that you make no use of ifort run-time libraries, as there is no run-time library compatibility between ifort and gfortran. If the dependency on libgfortran was left over from linking against pre-built open source alternatives to MKL, I'm worried about confusion, when you apparently don't need any of the gfortran alternative libraries provided with MKL.