On Wed, 05 Aug 2020 17:19:11 +0000 Leonard Lausen <lau...@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
signature.asc
Description: This is a digitally signed message part
