Bug#725673: libopenblas-base: No direct linking of openblas possible, always redirects to libblas.so.3.

[Sébastien Villemot]

Control: severity -1 wishlist
Control: tags -1 - upstream

Le lundi 07 octobre 2013 à 11:06 +0200, Martin Koehler a écrit :
> Package: libopenblas-base
> Version: 0.2.8-2
> Severity: important
> Tags: upstream
> 
> Dear Maintainer,
> 
> I am using openblas on debian wheezy and linked my programs explicitly (for
> benchmarking purpose and not to run update-alternatives as root everytime)
> using
>  $ export LD_LIBRARY_PATH=/usr/lib/openblas-base/
>  $ gcc -o test.openblas -L/usr/lib/openblas-base test.c -lopenblas
> and got an binary which depends on libopenblas.so.
> 
> Now we update to Debian Testing/Jessie and the following happened:
>  $ export LD_LIBRARY_PATH=/usr/lib/openblas-base/
>  $ gcc -o test.openblas -L/usr/lib/openblas-base test.c -lopenblas
>  $ ldd test.openblas
>         linux-gate.so.1 (0xb76e5000)
>         libblas.so.3 => /usr/lib/libblas.so.3 (0xb65d5000)
>         libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb6426000)
>         libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xb63e2000)
>         libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0
> (0xb63c7000)
>         /lib/ld-linux.so.2 (0xb76e6000)
> 
> which does not any longer include Openblas directly and forces to use the
> update-alternative system. I figured out that this behavior was introduced to
> solve bug #687349 ( see the libblas3-soname.patch). I think this behavior is
> not helpful for every day live.  In contrast if a want to do the same using
> ATLAS I can link againf libf77blas and  libatlas and it works without this
> issue.
> 
> I think there must be another solution to solve bug #687349 without this "bad"
> soname trick. In case of ATLAS there is a separate library which contains all
> dependencies to ATLAS but it still allows to use ATLAS explicitly overriding
> the update-alternatives system.

First, I am convinced that the old behaviour (in wheezy) was buggy and
that the new behaviour (in jessie/sid) is right. The fact that the
soname was libopenblas.so.0 meant that programs linked with -lblas were
*not* respecting the alternatives system. This is actually a wider
problem than #687349. The fix was indeed to set the soname of the
library to libblas.so.3. I don't intend to revert that change.

Now, your problem is a bit different. You are manipulating the dynamic
linker (with the -L flag and also by modifying the LD_LIBRARY_PATH
variable) to directly link to openblas, bypassing the alternatives
system. This was working in wheezy, but more by chance rather than
because of a conscious choice by the maintainers.

However, I understand your need for the possibility to bypass the
alternatives system. The only solution that I see is to have a second
binary of the library, identical to the other one, except that it would
have the soname equal to libopenblas.so.0. Also, that binary would have
to go to /usr/lib/<multiarch>/ (without the trailing "openblas"
subdirectory), so that manipulating the linker with -L and
LD_LIBRARY_PATH would not be needed.

I am open to implement the above solution, even though I don't like too
much the duplication of binary code that it entails.

Sylvestre: do you have any better idea?

-- 
 .''`.    Sébastien Villemot
: :' :    Debian Developer
`. `'     http://www.dynare.org/sebastien
  `-      GPG Key: 4096R/381A7594

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/debian-science-maintainers/attachments/20131007/2aaf7e1e/attachment-0001.sig>