Bug#967951: OpenBLAS ILP64 with symbol suffixes

[Sébastien Villemot]

On Wed, 05 Aug 2020 17:19:11 +0000 Leonard Lausen <lausen at apache.org>
wrote:
> Package: libopenblas64-0
> Version: 0.3.10+ds-3
> 
> 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

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

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  https://www.debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/debian-science-maintainers/attachments/20230909/a6c113bb/attachment.sig>