-liomp5 -lpthread -I/opt/intel/mkl/10.0.3.020/include/ -L/opt/intel/mkl/10.0.3.020/lib/em64t/ Reproducible: Always
(sorry for that initial post, I literally tripped on my Return key) I am unable to compile CBLAS applications with MKL unless I add the following to the gcc (or ICC) command lines: -liomp5 -lpthread -I/opt/intel/mkl/10.0.3.020/include/ -L/opt/intel/mkl/10.0.3.020/lib/em64t/ Note that `echo $LDPATH|grep mkl` _does_ show /opt/intel/mkl/10.0.3.020/lib/em64t in there. -liomp5 <<-- USE=mpi -lpthread <<-- Needed for BOTH mkl-gfortran and mkl-gfortran-threads -L/opt/intel/mkl/10.0.3.020/lib/em64t/ <<-- if not set I get `ld: cannot find -liomp5` -I/opt/intel/mkl/10.0.3.020/include/ <<-- That one is required if the cblas interface is set to mkl-gfortran or mkl-gfortran-threads It's late...hope I didn't just do a snafu.
Hi Eric, Would it be possible for you to post a very brief proof of concept type code plus makefile that would allow me to reproduce this error? Thanks in advance, Markus
Created attachment 162437 [details] BLAS example using dgemv Sorry it took a while, I re-read the Gentoo BLAS documentation to realize I might have been trying to do something manually that should be done automativally (http://www.gentoo.org/proj/en/science/blas-lapack.xml). The way I build my apps are as such: gcc -lcblas -lm testblas.c That works with GOTO as blas and reference as cblas interface. Now if I switch to mkl-gfortran blas I get the following: gcc -lcblas -lm testblas.c /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/../../../../x86_64-pc-linux-gnu/bin/ld: warning: libblas.so.0, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/../../../../lib64/libcblas.so, not found (try using -rpath or -rpath-link) [...snip very long listing of missing references...] If I try with -lblas instead: gcc -lblas -lm testblas.c /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find libmkl_intel_lp64.so collect2: ld returned 1 exit status ...then reading the Docs I am finding out I should be compiling using pkg-config as such: gcc `pkg-config --cflags --libs blas` -lm testblas.c -o testblas And that worked...but, notice the following, I put `--libs blas`. Now If I switch back to goto: gcc `pkg-config --cflags --libs blas` -lm testblas.c -o testblas /tmp/cc6Of92m.o: In function `main': testblas.c:(.text+0xac): undefined reference to `cblas_dgemv' collect2: ld returned 1 exit status I get an error and have to put `--libs cblas`: gcc `pkg-config --cflags --libs cblas` -lm testblas.c -o testblas So my original problem of missing PATHs _might_ be related to not using pkg-config. The use of a custom tool on a plaform does cause me some problems in that it's making my code Gentoo specific (Makefile) but I'm beyond bothering with being cross-platform compliant. What does seem to remain a problem/confusion is that, depending on the underlying blas implementation, one has to select either -lblas or -lcblas. IMHO, one shouldn't have to use pkg-config to use the "default" system's cblas and blas, I do see pkg-config come in handy when one wants to use _another_ implementation which is not the default system blas...but that's duplicating the work of a user-level eselect module, which seems to be duplicating (or trying to duplicate) the work of `modules` (http://modules.sourceforge.net/) So this is either a usage problem with a slight bug in the definitions (-lcblas vs -lblas) or there is something missing in the environment preventing the simple usage of the BLAS routines.
Hi! (In reply to comment #3) [...] > The way I build my apps are as such: > > gcc -lcblas -lm testblas.c First of all, you should pass libraries after the source file when compiling an linking at once, i.e.: gcc testblas.c -lcblas -lm Secondly, you should not use -lblas, if your program is using C interface to BLAS routines, e.g. "cblas_dgem". Finally, if you switch between BLAS/CBLAS implementations in Gentoo using eselect, I suggest switching both BLAS and CBLAS libraries at the same time. Mixing different implementations not always works, especially when it comes to binary MKL and ACML libraries. So, in your case, if you want to try MKL, switch both BLAS and CBLAS at the same time: eselect blas set mkl-gfortran-threads eselect cblas set mkl-gfortran-threads Now you can try if: gcc testblas.c -lcblas -lm works. Hope this helps! BR, /Adam
(In reply to comment #4) > Hi! > > (In reply to comment #3) > [...] > > The way I build my apps are as such: > > > > gcc -lcblas -lm testblas.c > > First of all, you should pass libraries after the source file when compiling an > linking at once, i.e.: > gcc testblas.c -lcblas -lm Ah, that's good to know, I knew the libs had to be in a certain order but didn't know that also included the source file. > Secondly, you should not use -lblas, if your program is using C interface to > BLAS routines, e.g. "cblas_dgem". For some reason, I _had_ to use -lblas instead ...could that be due to source not being first? > Finally, if you switch between BLAS/CBLAS implementations in Gentoo using > eselect, I suggest switching both BLAS and CBLAS libraries at the same time. > Mixing different implementations not always works, especially when it comes to > binary MKL and ACML libraries. > > So, in your case, if you want to try MKL, switch both BLAS and CBLAS at the > same time: > eselect blas set mkl-gfortran-threads > eselect cblas set mkl-gfortran-threads > > Now you can try if: > gcc testblas.c -lcblas -lm > works. Nope: kyron@kyron ~/1_Files/1_ETS/1_Maitrise/Code/BLAS_test $ eselect cblas list Installed CBLAS for library directory lib64 [1] atlas [2] atlas-threads [3] mkl-gfortran * [4] mkl-gfortran-threads [5] reference kyron@kyron ~/1_Files/1_ETS/1_Maitrise/Code/BLAS_test $ eselect blas list Installed BLAS for library directory lib64 [1] atlas [2] atlas-threads [3] goto [4] mkl-gfortran * [5] mkl-gfortran-threads [6] reference kyron@kyron ~/1_Files/1_ETS/1_Maitrise/Code/BLAS_test $ gcc testblas.c -lcblas -lm -o testblas In file included from testblas.c:13: /usr/include/cblas.h:28:23: error: mkl_types.h: No such file or directory In file included from testblas.c:13: [snip long list of errors] I will work only if I use the following approach: gcc testblas.c `pkg-config --cflags --libs cblas` -lm -o testblas This is using mkl, now if I switch to using GOTO + refecrence for cblas the same command line also works. So the following is my conclusion: 1- place source as the first argument (thanks!) 2- use "`pkg-config --cflags --libs cblas`" ...Is this correct? Should one have to do this? I'm not sure this is the intended approach since it's non-portable. > Hope this helps! > > BR, > /Adam >
(In reply to comment #5) > > Secondly, you should not use -lblas, if your program is using C interface to > > BLAS routines, e.g. "cblas_dgem". > > For some reason, I _had_ to use -lblas instead ...could that be due to source > not being first? Do no know. But, I am sure that -lcblas is required when you use cblas_* functions in your program. > > Now you can try if: > > gcc testblas.c -lcblas -lm > > works. > Nope: > > kyron@kyron ~/1_Files/1_ETS/1_Maitrise/Code/BLAS_test $ eselect cblas list > Installed CBLAS for library directory lib64 > [1] atlas > [2] atlas-threads > [3] mkl-gfortran * > [4] mkl-gfortran-threads > [5] reference > kyron@kyron ~/1_Files/1_ETS/1_Maitrise/Code/BLAS_test $ eselect blas list > Installed BLAS for library directory lib64 > [1] atlas > [2] atlas-threads > [3] goto > [4] mkl-gfortran * > [5] mkl-gfortran-threads > [6] reference > kyron@kyron ~/1_Files/1_ETS/1_Maitrise/Code/BLAS_test $ gcc testblas.c -lcblas > -lm -o testblas > In file included from testblas.c:13: > /usr/include/cblas.h:28:23: error: mkl_types.h: No such file or directory > In file included from testblas.c:13: > [snip long list of errors] Obviously, it is not a problem of wrong or missing libraries, but the unknown location of the mkl_types.h header file. You need to pass additionally the correct path to this include file, e.g.: % gcc -I/opt/intel/mkl/10.0.4.023/include testblas.c -lcblas -lm Of course you can use `pkg-config --cflags cblas` to obtain correct CFLAGS with include directories, which is the recommended Gentoo approach. > I will work only if I use the following approach: > > gcc testblas.c `pkg-config --cflags --libs cblas` -lm -o testblas > > This is using mkl, now if I switch to using GOTO + refecrence for cblas the > same command line also works. So the following is my conclusion: > > 1- place source as the first argument (thanks!) I have not recommended this! First arguments are always preprocessor and compiler flags. > 2- use "`pkg-config --cflags --libs cblas`" ...Is this correct? Should one have > to do this? I'm not sure this is the intended approach since it's non-portable. This is not correct in my opinion. Once again: if you want to perform linking at the same time as compiling your program, you need to pass compiler flags (CFLAGS) and additional libraries (LIBS) as follows: % gcc $(CFLAGS) -o binary source.c $(LIBS) i.e. % gcc `pkg-config --cflags cblas` -o testblas testblas.c \ `pkg-config --libs cblas` BR, /Adam
