As per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878121 libopenblas64-0
has been made available containing the ILP64 build of OpenBLAS. Debian uses the
same symbol names in libopenblas64-0 and libopenblas0, which leads to conflicts
if users load multiple libraries into the same process that expect 32bit and 64bit interfaces respectively as the dynamic loader will only resolve the symbols once.

For example, python3-numpy may depend on the 32bit libraries, but users can
compile a package against libopenblas64-0 and load both into the same Python
process.

I believe that for this reason Debian's Julia package bundles OpenBlas "compiled
with SONAME=libopenblas64_.so, INTERFACE64=1 and all symbols suffixed by "64_"
as of 1.2.0+dfsg-1. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905826

Why not provide libopenblas64_-0 packages with symbol name suffixes? This should
allow Julia package to stop bundling OpenBlas as well as ease the life of users
that want to compile against OpenBLAS ILP64 interface on Debian systems while
avoiding symbol name conflicts. This seems to be the approach taken by Fedora:
https://src.fedoraproject.org/rpms/openblas/blob/HEAD/f/openblas.spec

Thank you
Leonard

bin/bugreport.cgi?bug=878121 libopenblas64-0
Debian uses the
conflicts
32bit and 64bit interfaces respectively as the dynamic loader will only
resolve the symbols once.
users can
Python
OpenBlas "compiled
by "64_"
bin/bugreport.cgi?bug=905826
This should
life of users
systems while
by Fedora:

For the record, see also the file docs/distributing.md that explains
the current (and possibly future) conventions for distributing ILP64
builds.