Hi! * Sébastien Fabbro [2007-08-18 20:42]: >> [ stuff about blas-atlas not linking ] > should be fixed now.
Yes. Now it emerges fine... >> [ stuff about mkl not extracting ] > should be fixed too. Same here. Emerges fine as well. BTW, I have two more issues related to MKL and ACML. The ACML package from official portage tree installs it's header (acml.h) via a symlink into /usr/include. I remember that Donnie did this due to my report related to the IT++ library I maintain (sci-libs/itpp). This would be possible for acml.h (only one header file), but not for MKL headers (there are many of them). The problem is that now the IT++ ebuild can not automatically configure the use of FFT native interfaces from MKL and ACML, when they are used as BLAS and LAPACK external libs. It should work as follows: If one have ACML or MKL installed, there is no need to install FFTW additionally. To configure these specific FFT interfaces, the existence of <mkl_dfti.h> and <acml.h> headers is verified, but of course it does not work, because these headers are installed in vendor specific directories. I discussed this issue with Markus some time ago and I proposed to append unconditionally "-I/path/to/acml.h -I/path/to/mkl_dfti.h" to CPPFLAGS and pass it to the configure command. But this solution is a bit "dirty". Now I wonder how to make this work properly in the IT++ ebuilds. Maybe you have some ideas for this? >> PS. I also noticed that blas-goto does not work properly on my core2duo >> laptop (a bunch of BLAS-related tests in the IT++ library fail, whereas >> ACML, MKL, ATLAS and NetLib's BLAS works fine). But I guess this is an >> upstream issue... > > blas-goto builds and tests fine on all my boxes. Send me an off-list > email or file a bug to see what we can do. OK. Will do it. BR, /Adam -- .:. Adam Piatyszek - "ediap" .:. JID: ediap(at)jabber.org .:. .:. ediap(at)users.sourceforge.net .:. PGP key ID: 0x1F115CCB .:.
smime.p7s
Description: S/MIME Cryptographic Signature
