[Numpy-discussion] [ANN] numscons 0.3.0 release
Fri Jan 25 04:21:33 CST 2008
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 failure.
>> - When a perflib Check* succeeds, the meta library check checks that
>> 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
> 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:
in your site.cfg should say to CheckATLAS to avoid looking for atlas_enum.h
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
More information about the Numpy-discussion