Intel® oneAPI Math Kernel Library
Ask questions and share information with other developers who use Intel® Math Kernel Library.

Unable to link statically with intel mkl

Santosh_T_
Beginner
1,250 Views

My program contains C/C++/Fortran code.

I am able to dynamically link with mkl and run my program.

I am using the following command to statically link with mkl.

/appl/intelv2017/bin/ifort -Wl,--start-group /appl/intelv2017/mkl/lib/intel64/libmkl_intel_lp64.a /appl/intelv2017/mkl/lib/intel64/libmkl_sequential.a /appl/intelv2017/mkl/lib/intel64/libmkl_core.a -Wl,--end-group -lpthread -lm -ldl -nofor-main -cxxlib *.o -o main.exe

I get the following error when from the above command.

crossval.o: In function `crossval':
/tmp/test/crossval.f:51: undefined reference to `dpotrs_'
/tmp/test/crossval.f:59: undefined reference to `ddot_'
/tmp/test/crossval.f:74: undefined reference to `ddot_'
/tmp/test/crossval.f:83: undefined reference to `ddot_'
loglik.o: In function `loglik':
/tmp/test/loglik.f90:52: undefined reference to `dpotrf_'
/tmp/test/loglik.f90:103: undefined reference to `dpotrs_'
/tmp/test/loglik.f90:114: undefined reference to `ddot_'
/tmp/test/loglik.f90:120: undefined reference to `dpotrf_'
/tmp/test/loglik.f90:132: undefined reference to `ddot_'
/tmp/test/loglik.f90:134: undefined reference to `dpotrs_'
/tmp/test/loglik.f90:141: undefined reference to `ddot_'
/tmp/test/loglik.f90:153: undefined reference to `dpotrs_'
/tmp/test/loglik.f90:159: undefined reference to `ddot_'
/tmp/test/loglik.f90:182: undefined reference to `dpotri_'
make: *** [main.exe] Error 1

All of the above routines are called from fortran code. It is not able to find the mkl function calls.

How do I resolve this issue?

 

0 Kudos
1 Solution
mecej4
Honored Contributor III
1,250 Views

The items to be linked are presented to the linker in an incorrect order. When the linker first reads the library files, there are no unsatisfied externals in its list. Later, it reads the object files, and finds new unsatisfied externals in those object files. It then fails to find those externals in the libraries specified after the object files, if any.

See https://stackoverflow.com/questions/11893996/why-does-the-order-of-l-option-in-gcc-matter ..

View solution in original post

0 Kudos
2 Replies
mecej4
Honored Contributor III
1,251 Views

The items to be linked are presented to the linker in an incorrect order. When the linker first reads the library files, there are no unsatisfied externals in its list. Later, it reads the object files, and finds new unsatisfied externals in those object files. It then fails to find those externals in the libraries specified after the object files, if any.

See https://stackoverflow.com/questions/11893996/why-does-the-order-of-l-option-in-gcc-matter ..

0 Kudos
Santosh_T_
Beginner
1,250 Views

Thanks. It worked. :)

mecej4 wrote:

The items to be linked are presented to the linker in an incorrect order. When the linker first reads the library files, there are no unsatisfied externals in its list. Later, it reads the object files, and finds new unsatisfied externals in those object files. It then fails to find those externals in the libraries specified after the object files, if any.

See https://stackoverflow.com/questions/11893996/why-does-the-order-of-l-opt... ..

0 Kudos
Reply