Hi, I just installed sci-libs/itpp-3.10.1 and the configure wouldn't correctly detect my atlas installation. After some tests I found that I had to remove the "=-lblas" from "--with-blas=-lblas" in the configure command-line in the ebuild to make configure actually check for -latlas. But there is also a second bug: I have installed sci-libs/blas-atlas-3.6.0-r1 and sci-libs/lapack-atlas-3.6.0-r1 and they do not install libraries named libf77blas.*, so I had to create symlinks /usr/lib/libf77blas.a -> blas/atlas/libblas.a /usr/lib/libf77blas.so -> blas/atlas/libblas.so /usr/lib/libf77blas.so.0 -> blas/atlas/libblas.so.0 to make the configure checks succeed. I am not sure if the latter is a bug in blas-atlas, in itpp or in itpp upstream, though. The blas/atlas/libblas.* obviously contain the F77 routines. I had to make BOTH changes for configure to agree that atlas is indeed installed.
Hi Jochen, Thanks for your report. Could you please make sure using blas-config that your blas installation is properly set up, i.e., the links /usr/lib/libblas.a -> blas/atlas/libblas.a /usr/lib/libblas.so -> blas/atlas/libblas.so* /usr/lib/libblas.so.0 -> blas/atlas/libblas.so.0* exist! In this case the switch "--with-blas=-lblas" should work. If this doesn't fix the problem please post "emerge --info" and the output of "blas-config -l". Thanks, Markus
Hi Markus, just to make sure I have checked all settings again, but the result is the same. Here is what I did in detail: # rm /usr/lib/libf77blas.* [removing my handmade links] # mv /usr/local/portage/sci-libs/ /usr/local/portage/test [moving my overlay ebuild away] # blas-config -l [checking what's there] Available C profiles: [1] ATLAS Available F77 profiles: [1] ATLAS # blas-config ATLAS [just to make sure] * /usr/lib/libcblas.so -> blas/atlas/libcblas.so * /usr/lib/libcblas.so.0 -> blas/atlas/libcblas.so.0 * /usr/lib/libcblas.a -> blas/atlas/libcblas.a * /usr/lib/libblas.so -> blas/atlas/libblas.so * /usr/lib/libblas.so.0 -> blas/atlas/libblas.so.0 * /usr/lib/libblas.a -> blas/atlas/libblas.a >>> Regenerating /etc/ld.so.cache... # blas-config --f77libs [it knows to use -lblas, not -lf77blas] -L/usr/lib/blas/atlas -lblas # lapack-config -l [I know it shouldn't be related but still ...] Available F77 profiles: [1] ATLAS # lapack-config ATLAS [... just to make absolutely sure] * /usr/lib/liblapack.so -> lapack/atlas/liblapack.so * /usr/lib/liblapack.so.0 -> lapack/atlas/liblapack.so.0 * /usr/lib/liblapack.a -> lapack/atlas/liblapack.a >>> Regenerating /etc/ld.so.cache... # emerge -av itpp These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sci-libs/itpp-3.10.1 USE="blas cblas doc fftw lapack -debug" 0 kB Total size of downloads: 0 kB Would you like to merge these packages? [Yes/No] yes >>> Emerging (1 of 1) sci-libs/itpp-3.10.1 to / [...] [here comes the relevant part of configure output where it misses atlas] checking for dummy main to link with Fortran libraries... none checking for Fortran name-mangling scheme... lower case, underscore, extra underscore checking for sgemm_ in -lblas... yes checking for cblas_sgemm... no checking for cblas_sgemm... (cached) no checking for sgemm... no checking for cblas_sgemm in -lcblas... yes checking for cheev_... no checking for cheev_ in -lmkl_lapack32... no checking for cheev_ in -llapack... yes checking for DftiComputeForward... no checking for DftiComputeForward in -lmkl... no checking for zfft1dx... no checking for zfft1dx in -lacml... no checking for fftw_plan_dft_1d in -lfftw3... yes checking fftw3.h usability... yes checking fftw3.h presence... yes checking for fftw3.h... yes checking for ANSI C header files... (cached) yes [...][and the (wrong) result] External libs: - BLAS ........... : yes * MKL .......... : no * ACML ......... : no * ATLAS ........ : no - CBLAS .......... : yes - LAPACK ......... : yes - FFT ............ : yes * MKL .......... : no * ACML ......... : no * FFTW ......... : yes [...] For comparison, here are the configure bits using my overlay (without the "=-lblas") and the libf77blas.* links: [...] checking for dummy main to link with Fortran libraries... none checking for Fortran name-mangling scheme... lower case, underscore, extra underscore checking for sgemm_... no checking for sgemm_ in -lmkl... no checking for sgemm_ in -lacml... no checking for ATL_xerbla in -latlas... yes checking for sgemm_ in -lf77blas... yes checking for cblas_dgemm in -lcblas... yes checking for cblas_sgemm... yes checking for cheev_... no checking for cheev_ in -lmkl_lapack32... no checking for cheev_ in -llapack... yes checking for DftiComputeForward... no checking for DftiComputeForward in -lmkl... no checking for zfft1dx... no checking for zfft1dx in -lacml... no checking for fftw_plan_dft_1d in -lfftw3... yes checking fftw3.h usability... yes checking fftw3.h presence... yes checking for fftw3.h... yes checking for ANSI C header files... (cached) yes [...][and the (right) result] External libs: - BLAS ........... : yes * MKL .......... : no * ACML ......... : no * ATLAS ........ : yes - CBLAS .......... : yes - LAPACK ......... : yes - FFT ............ : yes * MKL .......... : no * ACML ......... : no * FFTW ......... : yes [...] It looks like configure never touches -latlas in the unpatched version. For completeness, here is my emerge --info: Portage 2.1_pre10-r1 (default-linux/x86/2005.0, gcc-3.4.5, glibc-2.3.6-r3, 2.6.16-suspend2-r4 i686) ================================================================= System uname: 2.6.16-suspend2-r4 i686 Intel(R) Pentium(R) M processor 1700MHz Gentoo Base System version 1.6.14 dev-lang/python: 2.4.2 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -march=pentium4 -funroll-loops -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/share/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=pentium4 -funroll-loops -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://mirror.pacific.net.au/linux/Gentoo" LDFLAGS="-Wl,-O1" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X a52 aac acl acpi activefilter alsa arts artswrappersuid asf audiofile avi berkdb bitmap-fonts bzip2 cairo cddb cdparanoia cdr cli crypt css cups curl dga dhcp doc dts dv dvd dvdr dvdread edl emacs encode enscript exif fame ffmpeg flac foomaticdb fortran fpx gcj gdbm gif gimp gimpprint glitz glut gmp gphoto2 gpm graphviz gs icc idn ieee1394 imagemagick imlib immqt ipv6 isdnlog java javascript jbig jce jpeg jpeg2k kde kdeenablefinal kerberos latex lcms ldap libg++ libwww live lzo lzw-tiff mad mailwrapper mikmod mmx mmxext mng motif mozsvg mp3 mpeg mplayer mppe-mppc musepack musicbrainz mysql ncurses network nls nodrm nptl nptlonly nsplugin nvidia objc odbc ogg oggvorbis openexr opengl pam pcre pdflib perl pic png ppds pppd preview-latex python qt quicktime readline real reflection rle rtc sasl scanner session slp sndfile speex spell spl sse sse2 ssl svg tcltk tcpd tetex theora threads tiff truetype truetype-fonts type1-fonts ucs2 udev unicode usb vcd vidix vorbis wifi win32codecs wmf xanim xine xml xml2 xorg xpm xprint xv xvid xvmc zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux userland_GNU video_cards_none video_cards_nvidia" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LINGUAS
Hi Jochen, I think my previous post was confusing since I misunderstood the problem and I will try to explain what is going on. I've also cc'd one of the itpp developers to this bug so he can correct me if necessary. The fact that the ebuild links against blas instead of atlas is actually the correct behavior since we want to link against whatever is provided by /usr/lib/libblas, which is what "--with-blas=-lblas" does. As a matter of fact, is you're using ATLAS' blas implementation then its libblas provides you with optimized functions; no need for linking against atlas here. best, Markus
Ah, OK! So the only confusing thing is the configure output which says "ATLAS: no", although the libblas is actually the one provided by atlas. I wonder whether this is worth an einfo and/or a comment in the ebuild. What would happen to people who install the old sci-libs/atlas instead of blas-atlas, though? Anyway, that is not my problem :-) Thanks and cheers, Jochen
(In reply to comment #4) > Ah, OK! So the only confusing thing is the configure output which says > "ATLAS: no", although the libblas is actually the one provided by atlas. > I wonder whether this is worth an einfo and/or a comment in the ebuild. > What would happen to people who install the old sci-libs/atlas instead of > blas-atlas, though? Anyway, that is not my problem :-) Hi! Thanks Markus for your correct answer to this issue. Jochen: The confusing thing with "ATLAS: no" in the configure status is inevitable, since when we explicitly pass "--with-blas=blas" to the configure script, the detection mechanism just checks if the passed library provides blas. Therefore, extra checks for atlas are not executed. But, anyway, the IT++ will link to the optimised blas library, so from the user point of view, everything is OK. As for the sci-libs/atlas, we shouldn't bother with this package, because it is going to be removed from the portage tree ;-) We might consider adding some einfo to the ebuild if you like. BR, /ediap
Thanks again for your competent and quick replies. I think you should add an einfo to the ebuild since clueless people like myself would interpret "ATLAS: no" as not having picked up atlas. The other alternative I see is an upstream change to the configure output (e.g. adding the actual path of the -lblas that has been picked up in the configuration summary and maybe even an explanatory note that -latlas is not explicitely needed if -lblas is the tuned version). Anyway, this is just my 2c. I'll leave closing this bug to you (not sure what the appropriate resolution is). Cheers, Jochen
(In reply to comment #5) > Thanks Markus for your correct answer to this issue. Hi Adam, Thank you for your reply! It is much appreciated:) > As for the sci-libs/atlas, we shouldn't bother with this package, because it is > going to be removed from the portage tree ;-) Yeah, thanks for the reminder! I really have to make sure to finally remove those old blas/atlas ebuilds from the tree. They are on my to-do list which unfortunately has grown pretty long recently. @Jochen: I am glad we could answer your question and I will think about adding a brief note to the ebuild next time we bump it. I'll close the bug as invalid since it turned out not to be one! Thanks anyway for looking into this so closely. best, Markus
