[Numpy-discussion] PR, extended site.cfg capabilities

Nick Papior Andersen nickpapior at gmail.com
Tue Feb 24 08:51:18 EST 2015


2015-02-24 14:31 GMT+01:00 Julian Taylor <jtaylor.debian at googlemail.com>:

> On 02/24/2015 02:16 PM, Nick Papior Andersen wrote:
> > Dear all,
> >
> > I have initiated a PR-5597 <https://github.com/numpy/numpy/pull/5597>,
> > which enables the reading of new flags from the site.cfg file.
> > @rgommers requested that I posted some information on this site,
> > possibly somebody could test it on their setup.
>
> I do not fully understand the purpose of these changes. Can you give
> some more detailed use cases?
>
>
> >
> > So the PR basically enables reading these extra options in each section:
> > runtime_library_dirs : Add runtime library directories to the shared
> > libraries (overrides the dreaded LD_LIBRARY_PATH)
>
> LD_LIBRARY_PATH should not be used during compilation, this is a runtime
> flag that numpy.distutils has no control over.
> Can you explain in more detail what you intend to do with this flag?
>
Yes, but in my case I almost never set LD_LIBRARY_PATH, instead I link with
the runtime library directory so that LD_LIBRARY_PATH need not be set.
Consider this output from linalg/lapack_lite.so
$> echo $LD_LIBRARY_PATH

$>ldd lapack_lite.so
  libopenblas.so.0 => not found
$> echo $LD_LIBRARY_PATH
/path/to/openblas/lib
$>ldd lapack_lite.so
  libopenblas.so.0 => /path/to/openblas/lib/libopenblas.so.0

However, if I compile numpy with
runtime_library_dirs = /path/to/openblas/lib
in the openblas section, then the output would be
$> echo $LD_LIBRARY_PATH

$>ldd lapack_lite.so
  libopenblas.so.0 => /path/to/openblas/lib/libopenblas.so.0

I.e. screw-ups in LD_LIBRARY_PATHS can be circumvented.


> > extra_compile_args: Adds extra compile flags to the compilation
>
> extra flags to which compilation?
> site.cfg lists libraries that already are compiled. The only influence
> compiler flags could have is for header only libraries that profit from
> some flags. But numpy has no support for such libraries currently. E.g.
> cblas.h (which is just a header with signatures) is bundled with numpy.
> I guess third parties may make use of this, an example would be good.
>
The way I see distutils in numpy is that it extends the generic distutils
package so that packages relying on numpy can compile their software the
way they want.
In some of the extra software I work with, using numpy's distutils to link
to lapack/blas is easy, but adding specific compilation flags to sources is
not so easy (requires editing the compiler sources).
Also, when numpy compiles the lapack_litemodules.c it does so by the
generic flags in the compilers specified in the numpy distribution, however
now it also uses the flags provided in extra_compile_args from the lapack
section of site.cfg.
In that regard I would not consider numpy as having "no support" as some
packages does in fact use it.


> > extra_link_args: Adds extra flags when linking to libraries
>
> This flag may be useful.
> It could be used to pass options required during linking, like
> -Wl,--no-as-needed that is sometimes needed to link with gsl.
> Possibly also useful for link time optimizations.
>
Exactly, the runtime_library_dirs can be considered a shorthand for:
extra_link_args = -Wl,-rpath=<dir1> -Wl,-rpath=<dir2>
So you might consider it superfluous, but the intrinsic distutils package
allows both abstractions, so why not allow them both?

>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>


I hope this clarified a bit.
Thanks for the questions.

-- 
Kind regards Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20150224/93735d2b/attachment.html>


More information about the NumPy-Discussion mailing list