[Numpy-discussion] [ANN] numscons 0.3.0 release
Charles R Harris
Fri Jan 25 18:04:00 CST 2008
On Jan 25, 2008 3:21 AM, David Cournapeau <email@example.com>
> Matthew Brett wrote:
> > Hi David,
> >>> Basically, I'm trying to understand the library discovery, linking
> >>> steps - ATLAS in particular.
> >> Don't trust the included doc: it is not up-to-date, and that's the part
> >> which I totally redesigned since I wrote the initial doc.
> >> - For a perflib check to succeed, I try to compile, link and run
> >> code snippets. Any failure means the Check* function will return
> >> - When a perflib Check* succeeds, the meta library check checks
> >> another code snippet can be compiled/linked/run.
> > Thanks - and I agree, for all the reasons you've given in later emails
> > that this seems like the way to go.
> > But, in the mean time, I've got problems with the perflib stuff.
> > Specifically, the scons build is not picking up the atlas library for
> > blas and lapack that works for the standard build. I'm on a 64 bit
> > system, providing an extra layer of complexity.
> I have never tested the thing on 64 bits (I don't have easy access to 64
> bits machine, which should change soon, hopefully), so it is not
> surprising it does not work now. I have taken this into account for the
> design, though (see below).
> > I've attached the build logs. I noticed that, for atlas, you check
> > for atlas_enum.c - but do you in fact need this for the build?
> Now. I just wanted one header specific to atlas. It looks like not all
> version of ATLAS install this one, unfortunately (3.8, for example).
> > numpy.distutils seemed to be satisfied with cblas.h and clapack.h in
> > /usr/local/include/atlas. It's no big deal to copy it from sources,
> > but was there a reason you chose that file?
> No reason, but it cannot be cblas.h (it has to be atlas specific;
> otherwise, it does not make sense). The list of headers to check can be
> empty, though.
> > The test for linking to blas and lapack from atlas fails too - is this
> > a false positive?
> Hmm, if atlas check does not work, it sounds like a right negative to me
> :) If ATLAS is not detected correctly, it won't be used by blas/lapack
> checkers. Or do you mean something else ?
> > For both numpy.distutils and numpyscons, default locations of
> > libraries do not include the lib64 libraries like /usr/local/lib64
> > that us 64 bit people use. Is that easy to fix?
> Yes, it is easy, in the sense that nothing in the checkers code is
> harcoded: all the checks internally uses BuildConfig instances, which is
> like a dictionary with default values and a restricted set of keys (the
> keys are library path, libraries, headers, etc...). Those BuildConfig
> instances are created from a config file (perflib.cfg), and should
> always be customizable from site.cfg
> The options which can be customized can be found in the perflib.cfg
> file. For example, having:
> htc =
> in your site.cfg should say to CheckATLAS to avoid looking for
> To make 64 bits work by default is a bit more complicated. I thought a
> bit about the problem: that's why the checkers do not use BuildConfig
> instances directly, but request them through a BuildConfigFactory. One
> problem is that I don't understand how 64 bits libraries work; more
> precisely, what is the convention of library path ? Is there a lib64 for
> each lib directory (/lib64, /usr/lib64, /usr/local/li64) ? Should the
> standard ones (/lib, /usr/lib) checked at all, after the 64 bits
> counterpart ?
It varies with the Linux distro. The usual convention (LSB, I think) uses
/usr/local/lib64, but Debian and distros derived from Debian use
/usr/local/lib instead. That's how it was the last time I checked, anyway. I
don't know what Gentoo and all the others do.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Numpy-discussion