Re: libjulia-openblas64 (Was: plan of deep learning team for next stable release?
Hi Leonard,
On Sat, Nov 28, 2020 at 03:27:25AM +0000, Leonard Lausen wrote:
> Using ILP64 ABI without mangled symbols (as provided by <libblas64.so.3>
> virtual package) easily leads to problems. Consider a user compiles some
> native code for a Python package against libblas64.so.3 but also use
> `pip install --user` to obtain a binary wheel of NumPy.
>
> NumPy redistributes libopenblasp-r0-edd6b1a3.3.9.dev.so in their pip
> wheels. Thus the user will run into segfaults when using both NumPy and
> their native code in the same Python process. Either NumPy will get to
> use the blas64 symbols where it expects blas symbols, or the locally
> compiled code will get to use the blas symbols (provided by
> libopenblasp-r0-edd6b1a3.3.9.dev.so) where it expects the blas64
> symbols. It just depends if the user first imports NumPy or their custom
> package.
>
> Now we could say that NumPy should statically link their libopenblas,
> but I'm sure there are similar packages on Pypi and it may be hard to
> get all of them fixed.
>
> Thus a virtual package <libblas64.so.3> is not sufficient for use-cases
> where users don't compile all their code themselves, and ILP64 ABI with
> mangled symbols is needed. Further, Debian would be unable to package
> both Python packages depending on libblas and libblas64 as users may
> import both packages in the same process.
>
> With that said, do you think it would make sense to find a more generic
> name than libjulia-openblas64 and possibly providing a virtual package
> for the mangled ILP64 ABI?
First, I don't know whether there is an existing convention for the
BLAS64 with mangled ABI outside the julia community.
Second, if the mangled ILP64 ABI is really something demanded by the
industry, why is Intel's MKL blind to such demand? Who will mix the
usage of BLAS and BLAS64, and really process something that cannot be
handled by BLAS32 through numpy? I have no idea on these questions, so
I'm not sure whether going further on this direction is valuable.
Reply to: