| Summary: | sci-libs/mkl-9.0.018.ebuild misses gfortran and "-lpthread" | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Adam Piątyszek <ediap> |
| Component: | New packages | Assignee: | Gentoo Science Related Packages <sci> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | 2007.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Adam Piątyszek
2007-06-08 10:37:34 UTC
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. |
