Re: Challenge from Julia's non-standard vendored openblas"64_"
Hi Phil,
On 2019-07-28 10:14, Phil Morrell wrote:
> Without knowing anything more than what you've written here (which I
> didn't find too long), it sounds like maintenance burden is the concern.
The situation forces we Julia package maintainers to decide whether
to use such a non-standard openblas variant. If we did't link against
it, the built-in package manager (similar to python's pip) will be
hard for Debian users to use. If we linked against it, we get a weird
and duplicated binary in the archive but the usefulness wouldn't be
harmed.
> Am I right in thinking that there still exists non-Julia software for
> which your solution is cleaner than symbol mangling? Is that LAPACK?
The 64-bit indexing variant is common in the scientific computing area.
Providing the BLAS64/LAPACK64 alternative group without mangling symbol
names makes sense, because the other BLAS64/LAPACK64 alternatives such
as BLIS and intel's MKL don't mangle symbol.
> What you would do today if you were packaging it from scratch? If you
> would pick the Julia approach for ease of maintenance then a SONAME
> transition seems "simple" enough. If you would implement the cleaner
> no-mangling approach, then a libopenblas-julia compatibility dependency
> (option 2) would isolate the problem to the julia ecosystem.
I tend to choose option 3. Expecially if I'm packaging it from scratch.
Reply to: