Bugzilla Bug 131890

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