Hi! I would like to report two problems when using the latest mkl version from portage on an amd64 platform: 1) The ebuild does not support gfortran yet, but this is now the default stable Fortran compiler in Gentoo (since GCC 4.0.0). I suggest adding gfortran in line 48: FORTRAN="ifc g77 gfortran" I can confirm that it is possible to link other programs to MKL using gfortran. At least I was able to run all test programs from IT++ library (sci-libs/itpp). 2) When I was trying to link IT++ library with CBLAS and LAPACK provided by MKL, I encuntered the following problem: configure:25354: checking for sgemm_ in -lblas configure:25392: x86_64-pc-linux-gnu-g++ -o conftest conftest.cpp -lblas >&5 /opt/intel/mkl/9.0/lib/em64t/libguide.so: undefined reference to `pthread_atfork' collect2: ld returned 1 exit status Adding "-lpthread" to LIBS solved this problem, i.e.: % LIBS=-lpthread ebuild itpp-3.99.1.ebuild test worked fine. BR, /ediap PS. My emerge --info is as follows: Portage 2.1.2.7 (default-linux/amd64/2007.0, gcc-4.1.2, glibc-2.5-r3, 2.6.20-gentoo-r8 x86_64) ================================================================= System uname: 2.6.20-gentoo-r8 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ Gentoo Base System release 1.12.9 Timestamp of tree: Tue, 05 Jun 2007 08:00:01 +0000 dev-lang/python: 2.4.4-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -msse3 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=athlon64 -msse3 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="buildpkg distlocks metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://trumpetti.atm.tut.fi/gentoo/ http://gentoo.prz.rzeszow.pl http://gentoo.zie.pg.gda.pl " MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="acl amd64 bash-completion berkdb bitmap-fonts cli cracklib crypt cups dri emacs fortran gdbm gpm iconv isdnlog libg++ midi mmx mudflap ncurses nls nptl nptlonly openmp pam pcre perl pppd python readline reflection session spl sse sse2 ssl tcpd truetype-fonts type1-fonts unicode xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus cyrix dummy fbdev glint i128 i810 mach64 mga neomagic nv r128 radeon rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa vga via vmware voodoo" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Hi Adam, I will take a look at it. Could you compile the fortran95 tests with gfortran as well? Sébastien
(In reply to comment #1) > I will take a look at it. Could you compile the fortran95 tests with gfortran > as well? Unfortunately not. I tried to manually modify the makefiles, which assume g77 as default GNU fortran compiler, but I got segmentation faults when running the tests. Maybe we should try with the latest release of MKL - version 9.1? /ediap
(In reply to comment #2) > Maybe we should try with the latest release of MKL - version 9.1? I can confirm that all tests works in version 9.1.018 when compiled with gfortran. Here are the required changes to the ebuild: --- mkl-9.0.018.ebuild 2007-06-01 03:06:29.000000000 +0200 +++ mkl-9.1.018.ebuild 2007-06-09 16:35:44.000000000 +0200 @@ -44,8 +44,7 @@ # setting up compilers INTEL_CC=gnu [[ "$(tc-getCC)" == "icc" ]] && INTEL_CC=icc - # gfortran still not compiling tests nor fortran95 interface - FORTRAN="ifc g77" + FORTRAN="ifc g77 gfortran" use fortran95 && FORTRAN="ifc" fortran_pkg_setup @@ -129,7 +128,7 @@ einfo "Testing ${testdir}" cd ${testdir} emake \ - F=gnu \ + F=gnu FC=${FORTRANC} \ lib${INTEL_ARCH} || die "emake ${testdir} failed" done } BR, /ediap
Hi Sébastien, One more issue related to "-lpthread" problem with MKL. It only exists for emt64t MKL libraries. There are no such linking problems with 32-bit libraries. Besides, I have another comment. Currently the libraries installed in /usr/lib/{blas,lapack}/mkl consist of only BLAS, CBLAS and LAPACK interfaces. This is realised with this step: cd "${S}"/tools/builder for x in blas cblas lapack; do emake \ export="${FILESDIR}"/${x}.list \ name=lib${x} \ ${INTEL_KERN} || die "emake ${x} failed" done and *.list files from ${FILESDIR}. But I would prefer to have the full libmkl.so linked to /usr/lib/libblas.so and /usr/lib/cblas.so and full libmkl_lapack.so (or libmkl_lapack32.so or libmkl_lapack64.so) as /usr/lib/liblapack.so. Similar installation approach is done for ACML. Now you might ask why I prefer such an approach? The reason is simple. Both the MKL and ACML libraries provides their own FFT optimised implementations. And the IT++ library I develop (sci-libs/itpp) can use these FFT implementations instead of the default FFTW3. But with the current MKL installation in Gentoo, the Dfti* interfaces are not available in the default location /usr/lib. I know that I could ask Markus to play with LDFLAGS and CPPFLAGS in the IT++ ebuilds, but this is not the best solution in our opinion. Eventually, it would be nice to additionally build Dfti* interfaces into a separate library, e.g. /usr/lib/libmkl_dft.so. Or even create a full set of MKL sublibraries in /usr/lib, i.e. libmkl_blas.so, libmkl_cblas.so, libmkl_lapack.so, libmkl_dft.so and libmkl_spblas.so. And then link the appropriate ones to libblas libcblas and liblapack using eselect. That is how ACML is installed in Gentoo. BTW, why do you use separate {blas,cblas,lapack}.list files in ${FILESDIR}, instead of the ones included in MKL (mkl-9.0.018/tools/builder)? Moreover: node01 builder # pwd /var/tmp/portage/sci-libs/mkl-9.0.018/work/mkl-9.0.018/tools/builder node01 builder # for i in blas* cblas* lapack*; do echo -n $i; cat $i |wc ;done blas_list 176 176 1255 cblas_list 166 166 2009 lapack_list 1284 1284 10142 node01 files # pwd /usr/portage/sci-libs/mkl/files node01 files # for i in blas* cblas* lapack*; do echo -n $i:; cat $i |wc ;done blas.list: 149 149 1050 cblas.list: 148 148 1783 lapack.list: 1291 1291 10195 It seems that cblas.list is missing one interface, as compared to blas.list. Best! /ediap
Hi Adam, I am actually in the process of testing mkl-9.1.018. There are a number of changes I am doing in the ebuild, which could resolve your issues. - linking with pthread: could be a reallocation problem (see below for non pic). Now this is a more general issue with the eselect mechanism, when an implementation needs extra libs to link with. We are facing this problem in an number of ebuilds. - building from {blas,cblas,lapack}_list: this was reminiscent from an older version where upstream separated the lapack implementations in different libraries. This is gone in the latest mkl, furthermore it was not pic for the shared library (basically it was extracting objects from a static to put them in a shared one). - fftw libs: the new version has a more complete fftw implementation. Are you suggesting an eselect mechanism for fftw? I am not sure there is an official ABI as for blas. The /opt/intel/mkl/*/lib* should be in the path when loading thanks to the env.d file, such that you don't need to specify LD_LIBRARY_PATH or CPPFLAGS. Let me know whether it does not work for you. For your it++ lib and users building on other linux than gentoo, should it be better to keep the mkl libraries in the standard default upstream does? It respects FHS too, while the acml ebuild does not. Now, the fftw wrapper does not build a shared libs (yet!). You can follow the changes on my lapack overlay, which I uploaded: http://dev.gentoo.org/~bicatali/lapack (not ready for general consumption yet). Thanks for testing! Sébastien
Hi! (In reply to comment #5) > - linking with pthread: could be a reallocation problem (see below for non > pic). > Now this is a more general issue with the eselect mechanism, when an > implementation needs extra libs to link with. We are facing this problem in an > number of ebuilds. OK. I see. [...] > - fftw libs: the new version has a more complete fftw implementation. Are you > suggesting an eselect mechanism for fftw? I am not sure there is an official > ABI as for blas. No. In fact we do not use FFTW interface from MKL in IT++. We use the vendor provided Dfti* routines declared in one of the MKL's include files. > The /opt/intel/mkl/*/lib* should be in the path when loading thanks to the > env.d file, such that you don't need to specify LD_LIBRARY_PATH or CPPFLAGS. > Let me know whether it does not work for you. I see. I think the problem is with explicit --with-blas=-lblas in itpp ebuilds, which is needed to use the blas and cblas selected by users (with eselect tool). Without this switch, libacml.* is detected first if installed, because it is in /usr/lib. And with this switch, when blas and cblas are found in /usr/lib, the Dfti* interfaces are not found in further configure checks, because the configure script expects to found them together with blas (MKL and ACML case)... > For your it++ lib and users building on other linux than gentoo, should it be > better to keep the mkl libraries in the standard default upstream does? It > respects FHS too, while the acml ebuild does not. Now, the fftw wrapper does > not build a shared libs (yet!). In my opinion it is better to use vendor specific destinations, unless they do not break some important rules... So I would stick to /opt/intel/mkl prefix and only create the appropriate links for blas, cblas and lapack in /usr/lib. Since we can nicely support library and include paths with env.d files, this should work well. Besides we still have eselect {blas,cblas,lapack}, so the actual location of MKL is not a problem... > You can follow the changes on my lapack overlay, which I uploaded: > http://dev.gentoo.org/~bicatali/lapack (not ready for general consumption yet). I have had a look on it. Impressive work! When do you expect to include these changes into the main portage tree? > Thanks for testing! You are welcome. BR, /ediap
should be fixed with the current mkl in the tree.
