On 10/07/2013 11:36 AM, mkbugreport.67791230...@inboxalias.com wrote: > Original email sent from: sebast...@debian.org > > 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? >
As far as I understand both ways, the one in wheezy and the one in jessie are not completely statisfying. After your explainations I think it would be a good idea to provide a second library with the other DT_SONAME set. It seems that this is already the way how it is done for ATLAS. (It provides a separate libblas.so.3 in atlas-base/atlas which is used for update alternatives). Introducing the same structure for OpenBLAS will give a great flexibility and solve both problems. The one with the SONAMEs in the update-alternative system and on the other hand it allows to link openblas directly. _________________________________________________________________ Send and receive anonymous emails to your inbox with InboxAlias. http://www.inboxalias.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org