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

[Olivier Grisel]

2014-03-28 22:55 GMT+01:00 Julian Taylor <jtaylor.debian at googlemail.com>:
> On 28.03.2014 22:38, Olivier Grisel wrote:
>> 2014-03-28 22:18 GMT+01:00 Nathaniel Smith <njs at pobox.com>:
>>> I thought OpenBLAS is usually used with reference lapack?
>>
>> I am no longer sure myself. Debian & thus Ubuntu seem to be only
>> packaging the BLAS part of OpenBLAS for the libblas.so symlink and
>> uses the reference implementation of lapack for the liblapack.so
>> symlink.
>
> You can link the reference lapack with any library providing a BLAS
> compatible API/ABI. ATLAS and OpenBlas are ABI compatible with reference
> BLAS which allows replacing the library via LD_PRELOAD or debian
> alternatives without recompiling.
>
> Both ATLAS and OpenBlas provide a subset of optimized lapack functions,
> but they are optional. On Debian/Ubuntu you can install ATLAS lapack but
> then you are also forced to use ATLAS blas.
>
> I am not familiar with how relevant the optimized parts of lapack for
> the general use case.
>
>>
>> I observed a sparse leastsqr bug when linking scipy against the full
>> OpenBLAS under OSX that I could not reproduce under with the openblas
>> + lapack combo shipped Ubuntu so there might be a difference. But that
>> could also be caused by a version / platform discrepancy between my
>> two setups.
>>
>
> what kind of a bug? wrong result or crash?

Here it is: https://github.com/scikit-learn/scikit-learn/issues/2986

I have not found the time to investigate yet.

> Which target did openblas use
> when compiling on macos? or was it a dynamic build? (see the name of the
> built static library)

I think I used target=NEHALEM that time (but not 100% sure).

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