[Numpy-discussion] Default builds of OpenBLAS development branch are now fork safe

[Olivier Grisel]

2014-02-20 23:56 GMT+01:00 Carl Kleffner <cmkleffner at gmail.com>:
> Hi,
>
> 2014-02-20 23:17 GMT+01:00 Olivier Grisel <olivier.grisel at ensta.org>:
>
>> I had a quick look (without running the procedure) but I don't
>> understand some elements:
>>
>> - apparently you never tell in the numpy's site.cfg nor the scipy.cfg
>> to use the openblas lib nor set the
>> library_dirs: how does numpy.distutils know that it should dynlink
>> against numpy/core/libopenblas.dll
>
>
> numpy's site.cfg is something like: (64 bit)
>
> [openblas]
> libraries = openblas
> library_dirs = D:/devel/mingw64static/x86_64-w64-mingw32/lib
> include_dirs = D:/devel/mingw64static/x86_64-w64-mingw32/include
>
> or (32 bit)
>
> [openblas]
> libraries = openblas
> library_dirs = D:/devel32/mingw32static/i686-w64-mingw32/lib
> include_dirs = D:/devel32/mingw32static/i686-w64-mingw32/include

Thanks, what I don't understand is how the libopenblas.dll will be
found at runtime. Is it a specific "feature" of windows? For instance
how would the scipy/linalg/_*.so file know that the libopenblas.dll
can be found in $PYTHONPATH/numpy/core?

> Please adapt the paths of course and apply the patches to numpy.
>
>>
>> - how to you deal with the link to the following libraries:
>>     libgfortran.3.dll
>>     libgcc_s.1.dll
>>     libquadmath.0.dll
>>
> You won't need them. I build the toolchain statically. Thus you don't have
> to mess up with GCC runtime libs. You can check the dependencies with MS
> depends or with ntldd (included in the toolchain)

Great! I did not know it was possible. I guess that if we want to
replicate that for Linux and Mac we will have to also build custom
static GCC toolchains as well. Is there a good reference doc somewhere
on how to do so? When googling I only find posts by people who cannot
make their toolchain build statically correctly.

-- 
Olivier
http://twitter.com/ogrisel - http://github.com/ogrisel