On Saturday 07 May 2005 10:54 pm, Darren Dale wrote:
> Hi Danny!
>
> On Saturday 07 May 2005 7:57 pm, Danny van Dyk wrote:
> > Hi Darren,
> >
> > > I thought I might try to get some work done on a few science-related
> > > python packages. A reminder of what was at issue:
> >
> > I'm really sorry to have forgotten you and your BUG. I've been a bit
> > busy with my studies. You should have poked me earlier in regard to this
> > per mail ;-) I need poking or I get distracted :-/
>
> No problem. I didn't want to poke to much, I have been told that I
> sometimes (unintentionally) come across as pushy through email.
>
> > > Numeric, numarray and scipy all have the ability to link to blas,lapack
> > > and atlas libraries. By default, numeric and numarray will build
> > > against their own internal, and slower, libraries.
> > >
> > > I had submitted an ebuild for Numeric which, if USE=atlas, modified
> > > the install script to link to the libraries provided by lapack-atlas
> > > (and its dependency, blas-atlas), and made lapack-atlas a dependency.
> > > One of the devs improved upon my initial offering, suggesting that they
> > > were no longer using the atlas use flag, and changed the dependency to
> > > virtual lapack.
> >
> > 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.
I was not able to patch numeric-23.7.ebuild. Here are the contents of
the .rej:
***************
*** 7,28 ****
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() {
--- 7,33 ----
MY_P=${P/n/N}
S=${WORKDIR}/${MY_P}
+ DESCRIPTION="Numerical Python adds a fast, compact, multidimensional array
language facility to Python"
+ HOMEPAGE="http://numeric.scipy.org/";
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
+ virtual/blas"
src_unpack() {
unpack ${A}
+ cd ${S}
+ cp ${FILESDIR}/cblas.h ${S}/Include/
+ sed -i \
+ -e "s|\(library_dirs_list\ =\
\[\).*|\1\'/usr/$(get_libdir)\']|g" \
+ -e "s|\(libraries_list.*\)f77blas|\1blas|g" \
+ setup.py
}
src_install() {
>
> > > 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.
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.
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?
Darren
--
[email protected] mailing list
