-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Darren,
>>>Back to this, i had to modify the build a little more and i dropped your
>>>patch entirely in order to use sed. We need to use sed, as we have to
>>>set the library dir in setup.py. As this is lib64 on amd64 f.e, we have
>>>to use $(get_libdir) to refer to the right libdir. I have attached 2
>>>little patches against numeric-23.7 and numeric-23.8. They compile fine
>>>for me, and I'm now interested if you find any regressions. If they work
>>>for you, I'll add them to CVS ASAP (promised!!) :-)
> I emerged Numeric-23.8 using an overlay with your patch. Then I ran the two
> tests which are distributed in the Numeric tarball, which were successful,
> and I ran the ten tests from scipy (which uses Numeric) and they also were
> successful. In fact, they appear to be running about 20% faster than when I
> built from source, but I don't understand why.
:-D
> I was not able to patch numeric-23.7.ebuild. Here are the contents of
> the .rej:
I'll attach the complete ebuild for numeric-23.7 then...
>>>>Numeric, numarray, and scipy all need atlas specific information during
>>>>the build, if it is available. How can I get the atlas information into
>>>>the setup scripts, if it is appropriate to do so?
>>>You refer to cblas.h? I'll be adding it to numerics ${FILESDIR}, as
>>>cblas.h is licensed under BSD license. Legally, no problem ;-)
>>>>What happens if Numeric is built against lapack-atlas, and then I use
>>>>lapack-config to switch to MKL? Numeric would still be linked to
>>>>libatlas.*, is that a problem?
>>>
>>>No. Numeric is build against /usr/$(get_libdir)/liblapack.so, everytime.
>>>liblapack.so itself is a symlink to whatever you choose to let it point
>>>to. When you change that symlink to libfoo.so, numeric will use
>>>libfoo.so instead of ATLAS's liblapack.so.
>>I was more concerned about linking to /usr/lib/libatlas.*, and all the
>>files in /usr/include/atlas/. These are installed by lapack-atlas, and both
>>Scipy and Numeric will link to them if available.
Yeah, i didn't realize it numeric links to libblas _and_ liblapack _and_
libatlas
if all three are found :-/
> OK, now concerning ATLAS. Here is a snippet from emerge -v numeric, using the
> 23.8 patch:
> i686-pc-linux-gnu-gcc -pthread -shared -march=pentium4 -O3 -pipe
> -fomit-frame-pointer build/temp.linux-i686-2.4/Src/lapack_litemodule.o
> -L/usr/lib -llapack -lcblas -lblas -latlas -lg2c -o
> build/lib.linux-i686-2.4/lapack_lite.so
> Next I tried moving libatlas.* out of /usr/lib, to see if I could emerge
> numeric on a system without atlas. Again, emerge -v numeric:
> i686-pc-linux-gnu-gcc -pthread -shared -march=pentium4 -O3 -pipe
> -fomit-frame-pointer build/temp.linux-i686-2.4/Src/lapack_litemodule.o
> -L/usr/lib -llapack -lcblas -lblas -latlas -lg2c -o
> build/lib.linux-i686-2.4/lapack_lite.so
> /usr/lib/gcc/i686-pc-linux-gnu/3.4.3-20050110/../../../../i686-pc-linux-gnu/bin/ld:
>
> cannot find -latlas
> collect2: ld returned 1 exit status
> error: command 'i686-pc-linux-gnu-gcc' failed with exit status 1
> The problem is that 'atlas' is still listed in the libraries_list in
> setup.py.
> And it should be listed, if I am running numeric linked against lapack-atlas.
/usr/$(get_libdir)/libatlas.so is part of sci-libs/blas-atlas, you can
easily
find that if you run
qpkg -f /usr/lib/libatlas.so
> This issue of changing linear algebra libraries after compile time is enough
> to make my head spin. Wouldn't it be better to choose which libraries we link
> against at compile time, rather than at run time by using symlinks? The
> symlink idea seemed nice at first, but is it worth the trouble?
To make the facts clear: Both BLAS and LAPACK have standards for their
interfaces.
The only thing we're doing is two switch the provider of those function
on the fly. When - during
compile time - your application relies on i.e./usr/lib/liblapack.so, you
only have to make sure that this
it is a full LAPACK implementation. The problem we have here, is that we
don't have a separate provider
for the libatlas.so, as it comes with sci-libs/blas-atlas. So, if we
once link numeric against libatlas.so,
we may not remove it from system or numeric will break. The solution
would obviously be to have three
ebuilds for ATLAS: sci-libs/{atlas, blas-atlas, lapack-atlas}. This way,
we could
DEPEND="sci-libs/atlas virtual/blas virtual/lapack"
in numeric. I don't know if it is technically possible to split libatlas
from lib[c]blas in ATLAS, but I'll have
a look at it.
While we're at it: I added sci-libs/blas-atlas-3.7.10 to the tree.
BEWARE: this one is still package.mask'ed,
not due to the code, but due to the new ebuild. I'd like some testing
reports before I'll unleash this to testing.
Additionally, this package relies on app-admin/eclectic instead of
sci-libs/blas-config to switch between
BLAS implementations. eclectic comes with a manpage for the script
itslef as well as the blas module.
("man eclectic" or "man blas.eclectic") I haven't tried anything about
lapack-atlas-3.7.10, but I will at next
opportunity :-)
Danny
- --
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFChTmBaVNL8NrtU6IRArm9AKCOsDfHUOTqkZ+6ANMPxUcaxNaYxgCfV+Ex
r8OuqDbjlx7uC7R0RykEk+c=
=KcPB
-----END PGP SIGNATURE-----
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/dev-python/numeric/numeric-23.7.ebuild,v 1.7
2005/05/01 16:07:57 gmsoft Exp $
inherit distutils eutils
MY_P=${P/n/N}
S=${WORKDIR}/${MY_P}
DESCRIPTION="a fast, compact, multidimensional array language facility"
HOMEPAGE="http://www.pfdubois.com/numpy/";
SRC_URI="mirror://sourceforge/numpy/${MY_P}.tar.gz"
LICENSE="as-is"
SLOT="0"
KEYWORDS="~alpha ~amd64 hppa ~ia64 ~ppc ~ppc64 ~s390 sparc x86"
IUSE=""
# 2.1 gave sandbox violations see #21
DEPEND=">=dev-lang/python-2.2"
src_unpack() {
unpack ${A}
cd "${S}"
epatch "${FILESDIR}"/${P}.patch
}
src_install() {
distutils_src_install
distutils_python_version
#Numerical Tutorial is nice for testing and learning
insinto /usr/lib/python${PYVER}/site-packages/NumTut
doins Demo/NumTut/*
}
