Linking Blas & Lapack with Lapackpp

[soniasinghal]

Hi,

I recently downloaded and installed the MKL library for Linux (Suse). I wanted to use this with the C++ interface provided by lapack++ on source forge as I am not comfortable with Fortran. For installing lapack++ ( with the regular configure, make, make install setup ), lapack++'s configure does sanity checks on the blas/lapack libraries provided. It does this by compiling & linking the libraries with small code pieces. I get linking errors from MKL libraries.

------------------------

configure:22164: checking for sgemm_ in /scratch2/sonia/packages/mkl/lib/32/libmkl_ia32.a
configure:22197: gcc -o conftest -g -O2 conftest.c /scratch2/sonia/packages/mkl/lib/32/libmkl_ia32.a -L/afs/ece.cmu.edu/support/gcc/4.1.1/4.1.1-1/i386_suse93/image/usr/local/bin/../lib/gcc/i686-pc-linux-gnu/4.1.1 -L/afs/ece.cmu.edu/support/gcc/4.1.1/4.1.1-1/i386_suse93/image/usr/local/bin/../lib/gcc -L/usr/local/lib/gcc/i686-pc-linux-gnu/4.1.1 -L/afs/ece.cmu.edu/support/gcc/4.1.1/4.1.1-1/i386_suse93/image/usr/local/bin/../lib/gcc/i686-pc-linux-gnu/4.1.1/../../.. -L/usr/local/lib/gcc/i686-pc-linux-gnu/4.1.1/../../.. -lgfortranbegin -lgfortran -lm -lgcc_s >&5
/scratch2/sonia/packages/mkl/lib/32/libmkl_ia32.a(def_sgemm_omp.o): In function `mkl_blas_def_sgemm':
tmp_sgemm_omp.c:(.text+0x1e): undefined reference to `__kmpc_global_thread_num'
tmp_sgemm_omp.c:(.text+0xe0): undefined reference to `omp_in_parallel'
tmp_sgemm_omp.c:(.text+0xed): undefined reference to `omp_get_max_threads'
tmp_sgemm_omp.c:(.text+0x149): undefined reference to `__kmpc_ok_to_fork'
tmp_sgemm_omp.c:(.text+0x1e9): undefined reference to `__kmpc_fork_call'
tmp_sgemm_omp.c:(.text+0x204): undefined reference to `__kmpc_serialized_parallel'
tmp_sgemm_omp.c:(.text+0x2ad): undefined reference to `__kmpc_end_serialized_parallel'
tmp_sgemm_omp.c:(.text+0x2f4): undefined reference to `__kmpc_ok_to_fork'
tmp_sgemm_omp.c:(.text+0x3d4): undefined reference to `__kmpc_fork_call'
tmp_sgemm_omp.c:(.text+0x3ec): undefined reference to `__kmpc_serialized_parallel'
tmp_sgemm_omp.c:(.text+0x49d): undefined reference to `__kmpc_end_serialized_parallel'
/scratch2/sonia/packages/mkl/lib/32/libmkl_ia32.a(def_sgemm_omp.o): In function `L_mkl_blas_def_sgemm_276__par_loop0':
tmp_sgemm_omp.c:(.text+0x69d): undefined reference to `__kmpc_for_static_init_4'
tmp_sgemm_omp.c:(.text+0x80a): undefined reference to `__kmpc_for_static_fini'
/scratch2/sonia/packages/mkl/lib/32/libmkl_ia32.a(def_sgemm_omp.o): In function `L_mkl_blas_def_sgemm_296__par_loop1':
tmp_sgemm_omp.c:(.text+0x9c1): undefined reference to `__kmpc_for_static_init_4'
tmp_sgemm_omp.c:(.text+0xb38): undefined reference to `__kmpc_for_static_fini'
/scratch2/sonia/packages/mkl/lib/32/libmkl_ia32.a(p3_sgemm_omp.o): In function `mkl_blas_p3_sgemm':
tmp_sgemm_omp.c:(.text+0x1e): undefined reference to `__kmpc_global_thread_num'
tmp_sgemm_omp.c:(.text+0xe0): undefined reference to `omp_in_parallel'
tmp_sgemm_omp.c:(.text+0xed): undefined reference to `omp_get_max_threads'
tmp_sgemm_omp.c:(.text+0x149): undefined reference to `__kmpc_ok_to_fork'
tmp_sgemm_omp.c:(.text+0x1e9): undefined reference to `__kmpc_fork_call'
tmp_sgemm_omp.c:(.text+0x204): undefined reference to `__kmpc_serialized_parallel'
tmp_sgemm_omp.c:(.text+0x2ad): undefined reference to `__kmpc_end_serialized_parallel'
tmp_sgemm_omp.c:(.text+0x2f4): undefined re ference to `__kmpc_ok_to_fork'
tmp_sgemm_omp.c:(.text+0x3d4): undefined reference to `__kmpc_fork_call'
tmp_sgemm_omp.c:(.text+0x3ec): undefined reference to `__kmpc_serialized_parallel'
tmp_sgemm_omp.c:(.text+0x49d): undefined reference to `__kmpc_end_serialized_parallel'

.

.

.

configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE "lapackpp"
| #define VERSION "2.5.0"
| #define LAPACKPP_VERSION_MAJOR 2
| #define LAPACKPP_VERSION_MINOR 5
| #define LAPACKPP_VERSION_PATCHLEVEL 0
| #define LAPACKPP_VERSION_STRING "2.5.0"
| #ifdef __cplusplus
| extern "C" void std::exit (int) throw (); using std::exit;
| #endif
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_DLFCN_H 1
| #define STDC_HEADERS 1
| #define HAVE_STDLIB_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_BITS_CPP_TYPE_TRAITS_H 1
| #define HAVE_NAMESPACES
| /* end confdefs.h. */
|
| /* Override any gcc2 internal prototype to avoid an error. */
| #ifdef __cplusplus
| extern "C"
| #endif
| /* We use char because int might match the return type of a gcc2
| builtin and then its argument prototype would still apply. */
| char sgemm_ ();
| #ifdef F77_DUMMY_MAIN
|
| # ifdef __cplusplus
| extern "C"
| # endif
| int F77_DUMMY_MAIN() { return 1; }
|
| #endif
| int
| main ()
| {
| sgemm_ ();
| ;
| return 0;
| }
-----------------

Any pointers would help.

Thanks,

~ Sonia

[TimP]

libmkl has references which require libguide, which in turn requires threading support. If your setup doesn't include g++ option -fopenmp, you would require -lpthread, after libguide, in accordance with the examples.

[joao_ventura]

I had a similar problem trying to compile a game source.

After I'd installed the MKL, I runned the /opt/intel/mkl/8.1/tools/environment/mklvars32.sh script to set the enviroment variables. Then, like "-lm" gcc flag for programs that use the math.h library, you have to place the MKL flag in your Makefile. In my case, my CC variable became

CC=icc -w -L /opt/intel/mkl/8.1/lib/32/ -lguide -lmkl_ia32

where "-L /opt/intel/mkl/8.1/lib/32/" specify the MKL 32 bits libraries location and "-lguide -lmkl_ia32" are the MKL flags.

Sorry for my English, it's not my first language. =c)
Bye.

[TimP]

You might find that libguide has to be linked after mkl,particularly iflibguide is static linked.

Makefile commonly puts link options in a separate variable from compile options. Putting them in $(CC) would work only if $(CC) is used as the link command.

When you use icc, it is better to set up so that the libguide which belongs to icc is linked unambiguously. As you have it set up, with the library order backwards, and both the MKL and the icc libguide.so and libguide.a on the search path, you invite discrepancies between what is seen at build time and what happens at run time. MKL 8.1 did in fact contain discrepancies inorganization of libguide, compared to what icc 9.1 expected.