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.
