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?
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 ..
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 ..
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... ..
For more complete information about compiler optimizations, see our Optimization Notice.