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
signature.asc
Description: This is a digitally signed message part