[Bug 861081] New: blas-devel symlinks libblas.so -> libblas.so.3.4.2 , rendering update-alternatives useless. Also for lapack-devel.
https://bugzilla.novell.com/show_bug.cgi?id=861081 https://bugzilla.novell.com/show_bug.cgi?id=861081#c0 Summary: blas-devel symlinks libblas.so -> libblas.so.3.4.2 , rendering update-alternatives useless. Also for lapack-devel. Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: Development AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: asmunder@stud.ntnu.no QAContact: qa-bugs@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:21.0) Gecko/20100101 Firefox/21.0 When blas-devel is installed or upgraded, it creates a symlink libblas.so -> libblas.so.3.4.2 (or similar). This does not play nice with update-alternatives, which expects libblas.so -> libblas.so.3 so that update-alternatives can change what libblas.so.3 points to. Please fix blas-devel to play nicely with other blas versions (e.g. openblas from the Science repo). The same is valid for lapack-devel. Please also fix lapack-devel. Reproducible: Always Steps to Reproduce: 1. Install blas-devel 2. Install openblas-devel from the Science repo 3. Use update-alternatives --config libblas.so.3 to change which BLAS is used Actual Results: libblas.so still links to the version from blas-devel, no matter what I specify using update-alternatives. Expected Results: libblas.so should link to the version I specified with update-alternatives -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=861081 https://bugzilla.novell.com/show_bug.cgi?id=861081#c zhang jiajun <jzhang@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jzhang@suse.com AssignedTo|bnc-team-screening@forge.pr |rguenther@suse.com |ovo.novell.com | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=861081 https://bugzilla.novell.com/show_bug.cgi?id=861081#c1 Richard Biener <rguenther@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Richard Biener <rguenther@suse.com> 2014-02-12 09:39:10 UTC --- What openblas expects and how it uses update-alternatives is simply completely broken. To link against openblas install openblas-devel, to link against blas install blas-devel. If openblas-devel were packaged correctly it would conflict with blas-devel with the duplicate file /usr/lib{,64}/libblas.so. So the bug lives entirely within openblas. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=861081 https://bugzilla.novell.com/show_bug.cgi?id=861081#c2 Åsmund Ervik <asmunder@stud.ntnu.no> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |asmunder@stud.ntnu.no --- Comment #2 from Åsmund Ervik <asmunder@stud.ntnu.no> 2014-02-12 09:49:59 UTC --- I'm sorry, what? You think that openblas-devel and blas-devel should conflict, such that I would not be able to install both on the same machine? If that is the official opinion of Novell then I would consider your Linux distros unfit for use on our computational clusters. Would you also have gfortran conflict with ifort since they're both Fortran compilers? To be more specific: we have some applications/users that require ordinary blas and some that require openblas. What do you expect me to tell our users if openblas fixes their "bug" as you call it? "Sorry, we can't install both simultaneously because Novell says so"? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=861081 https://bugzilla.novell.com/show_bug.cgi?id=861081#c3 --- Comment #3 from Richard Biener <rguenther@suse.com> 2014-02-12 10:16:44 UTC --- Yes, openblas-devel and blas-devel conflict as they both provide libblas.so. Applications are fine if the actual shared libraries do not conflict (well, if they would then a parallel install wouldn't work at all). I wonder if your users are allowed to change alternatives (which are system wide, so one user breaks the other?)? If they are allowed to change alternatives then they can be allowed to install/remove their desired *blas-devel package as well, no? That said, if you think that the alternatives mechanism is the way to go for providing libblas.so / liblapack.so (which might be so as those are quite "standard" names) then you have to coordinate this and get it done in the "right" way. The correct way is certainly not by alternativ-ing libblas.so.3 but by alternativ-ing libblas.so itself. Which of course needs alternative support from all packages that provide an alternative (not sure how you thought it could work without teaching the blas / lapack packages about the existence of alternatives of it) So, propose sth to opensuse-packaging/factory. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=861081 https://bugzilla.novell.com/show_bug.cgi?id=861081#c4 --- Comment #4 from Åsmund Ervik <asmunder@stud.ntnu.no> 2014-02-12 11:26:31 UTC --- My users are not allowed to change alternatives or install/remove packages. The important thing to note is that it has to work with both openblas and blas simultaneously for different users. What I'm trying to use alternatives for is ensuring that openblas is the default when they just specify -lblas -llapack when linking. Then the people who require the stability of reference blas need to specify it with -L/usr/lib64/libblas.so.3.4.2 I agree that "update-alternatives --config libblas.so" would make more sense, but currently it seems "update-alternatives --config libblas.so.3" is the one used. Perhaps Debian is to blame for this: https://wiki.debian.org/DebianScience/LinearAlgebraLibraries . Anyway, typing in "update-alternatives --config libblas.so.3" gives me (correctly) a choice between the various blas versions I have installed, and works perfectly when I override the blas-devel symlinks so it's libblas.so->libblas.so.3->libblas.so.3.4.2 . Unfortunately this gets overwritten whenever blas-devel is updated. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=861081 https://bugzilla.novell.com/show_bug.cgi?id=861081#c5 Richard Biener <rguenther@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |lnt-sysadmin@lists.lrz.de, | |scorot@free.fr Resolution|INVALID | --- Comment #5 from Richard Biener <rguenther@suse.com> 2014-02-12 11:38:38 UTC --- Ok, thanks for the hint. It seems that we inherited that "alternative" from Debian (update-alternatives comes from the dpkg package): # ls -l /etc/alternatives/lib* lrwxrwxrwx 1 root root 27 Dec 11 13:10 /etc/alternatives/libblas.so.3 -> /usr/lib64/libblas.so.3.4.2 lrwxrwxrwx 1 root root 29 Dec 11 13:10 /etc/alternatives/liblapack.so.3 -> /usr/lib64/liblapack.so.3.4.2 It seems somebody added update-alternatives support in this awkward way to lapack Sun Jan 13 00:04:56 UTC 2013 - scorot@free.fr - add update-alternative support to allow user to easily switch between several blas and lapack libraries and then the bug would be that it get's installed as default on update %post -n libblas3 %_sbindir/update-alternatives --install \ %{_libdir}/libblas.so.3 libblas.so.3 %{_libdir}/libblas.so.%{version} 50 /sbin/ldconfig That is, for $1 = 2 (update) the above is wrong? (I'm not familiar with update-alternatives) I still do not approve to the design from Debian. Added CCs for people that created the mess in the first place and reopening for now. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=861081 https://bugzilla.novell.com/show_bug.cgi?id=861081#c6 --- Comment #6 from Corot Sebastien <scorot@free.fr> 2014-02-14 20:58:49 UTC --- Hi All, I am the original commiter of the change in lapack package regarding the support of update-alternative. For your information you can find the discussion I had a year ago on the packaging mailing list at this place : http://lists.opensuse.org/opensuse-packaging/2013-01/msg00089.html. Michal agreed with my changes from the update-alternative point of view. The packaging guideline [1] does not mention any advise when package is updated instead of freshly installed. At the time I made the change in lapack the update-alternatives worked as expected for me. I do not understand why update alternative does no work anymore. Perhaps we should ask Michal for an advise ? The idea when i submited the change, was to allow a binary package (I.e. octave) build on obs against the reference blas to use a faster blas without rebuild and linking this binary. openblas and atlas provides the same symbols as the reference blas. So when loading and running octave from obs, octave will look for libblas.so.3 which can be any of the "true" libblas.so.3 but also libopenblas.so.0 or libatlas.so.3 if user or admin made the change with update-alternative. But if update-alternative is not the best tool for doing so, I would be please to hear for a better solution. Regarding the conflit mentionned above about the devel packages, currently there is no conflict between blas-devel, openblas-devel and atlas-devel for the following reasons : 1. they do not have conflicting files 2. they do not provide the same things. openblas-devel [2] and atlas-devel [3] do not provide libblas.so nor have liblas.so or liblapack.so in their files list. [1] http://en.opensuse.org/openSUSE:Packaging_Multiple_Version_guidelines [2] https://build.opensuse.org/package/binary/science/openblas?arch=x86_64&filename=openblas-devel-0.2.7-1.3.x86_64.rpm&repository=openSUSE_13.1 [3] https://build.opensuse.org/package/binary/science/libatlas3?arch=x86_64&filename=libatlas3-devel-3.10.1-14.5.x86_64.rpm&repository=openSUSE_13.1 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=861081 https://bugzilla.novell.com/show_bug.cgi?id=861081#c7 Dmitry Roshchin <dmitry@roshchin.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dmitry@roshchin.org --- Comment #7 from Dmitry Roshchin <dmitry@roshchin.org> 2014-06-17 13:04:53 UTC --- Looks like ldconfig breaks update-ulternatives mechanism, for example: dmitry@main:~/tmp/oct> sudo /usr/sbin/update-alternatives --auto libblas.so.3 update-alternatives: using /usr/lib64/libblas.so.3.4.2 to provide /usr/lib64/libblas.so.3 (libblas.so.3) in auto mode dmitry@main:~/tmp/oct> readlink /usr/lib64/libblas.so.3 /etc/alternatives/libblas.so.3 dmitry@main:~/tmp/oct> sudo /usr/sbin/update-alternatives --config libblas.so.3 There are 4 choices for the alternative libblas.so.3 (providing /usr/lib64/libblas.so.3). Selection Path Priority Status ------------------------------------------------------------ * 0 /usr/lib64/libblas.so.3.4.2 50 auto mode 1 /usr/lib64/atlas/libsatlas.so.3 20 manual mode 2 /usr/lib64/atlas/libtatlas.so.3 20 manual mode 3 /usr/lib64/libblas.so.3.4.2 50 manual mode 4 /usr/lib64/libopenblasp.so.0 20 manual mode Press enter to keep the current choice[*], or type selection number: 4 update-alternatives: using /usr/lib64/libopenblasp.so.0 to provide /usr/lib64/libblas.so.3 (libblas.so.3) in manual mode dmitry@main:~/tmp/oct> readlink /usr/lib64/libblas.so.3 /etc/alternatives/libblas.so.3 dmitry@main:~/tmp/oct> sudo /sbin/ldconfig /sbin/ldconfig: /usr/lib64/libopenblasp.so.0 is not a symbolic link dmitry@main:~/tmp/oct> readlink /usr/lib64/libblas.so.3 libblas.so.3.4.2 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=861081 https://bugzilla.novell.com/show_bug.cgi?id=861081#c8 --- Comment #8 from Richard Biener <rguenther@suse.com> 2014-06-17 13:11:36 UTC --- It's rather using alternatives in shared library links which breaks ldconfig. It clearly isn't ldconfigs fault. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=861081 https://bugzilla.novell.com/show_bug.cgi?id=861081#c9 --- Comment #9 from Dmitry Roshchin <dmitry@roshchin.org> 2014-06-17 13:25:26 UTC --- (In reply to comment #8)
It's rather using alternatives in shared library links which breaks ldconfig. It clearly isn't ldconfigs fault.
But in any case we need solution for switching between BLAS libraries. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=861081 https://bugzilla.novell.com/show_bug.cgi?id=861081#c10 --- Comment #10 from Richard Biener <rguenther@suse.com> 2014-06-17 13:49:49 UTC --- (In reply to comment #9)
(In reply to comment #8)
It's rather using alternatives in shared library links which breaks ldconfig. It clearly isn't ldconfigs fault.
But in any case we need solution for switching between BLAS libraries.
Well, install a different one! (of course they happen to have different SONAME and thus comment#6 doesn't work) The idea in comment#6 would be workable with stub shared libraries with a common SONAME that dt-need the individual blas libraries. To switch blas implementations simply install the appropriate stub library. Just don't share that SONAME with one of the implementations. --- You can make the update-alternative work with ldconfig if you move all the shared libs to paths that are not in ld.so.conf. Then you can use symlinks to link to them. (Which is of course agains the shared library packaging policy). Which also means it probably works when you uninstall lapack/blas. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=861081 https://bugzilla.novell.com/show_bug.cgi?id=861081#c11 --- Comment #11 from Richard Biener <rguenther@suse.com> 2014-06-17 13:55:58 UTC --- (In reply to comment #10)
(In reply to comment #9)
(In reply to comment #8)
It's rather using alternatives in shared library links which breaks ldconfig. It clearly isn't ldconfigs fault.
But in any case we need solution for switching between BLAS libraries.
Well, install a different one! (of course they happen to have different SONAME and thus comment#6 doesn't work)
The idea in comment#6 would be workable with stub shared libraries with a common SONAME that dt-need the individual blas libraries. To switch blas implementations simply install the appropriate stub library. Just don't share that SONAME with one of the implementations.
For example using
echo > t.c gcc t.c -o libblasstub.so -Wl,-soname=libblasstub.so -shared -nostdlib -lblas
and then linking against -lblasstub You can then replace libblasstub.so in the system with a different one DT_NEEDing another implementation. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=861081 https://bugzilla.novell.com/show_bug.cgi?id=861081#c12 --- Comment #12 from Dmitry Roshchin <dmitry@roshchin.org> 2014-06-17 18:51:14 UTC --- We can use the same solution as Debian: /usr/lib/libblas.so.3 /usr/lib/liblapack.so.3 /usr/lib/blas/* /usr/lib/lapack/ /usr/lib/atlas/* /usr/lib/openblas/* there *.so.3 created by update-alternatives. But which variant is better? /usr/lib/blas/libblas.so /usr/lib/blas/libblas.so.3 /usr/lib/blas/libblas.so.3.5.0 or /usr/lib/libblas.so /usr/lib/blas/libblas.so.3.5.0 Looks like there is no conflict between -devel packages. Using of stub libraries is more difficult, in this case we need to patch applications. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=861081 https://bugzilla.novell.com/show_bug.cgi?id=861081#c13 --- Comment #13 from Richard Biener <rguenther@suse.com> 2014-06-18 07:43:30 UTC --- (In reply to comment #12)
We can use the same solution as Debian:
/usr/lib/libblas.so.3 /usr/lib/liblapack.so.3 /usr/lib/blas/* /usr/lib/lapack/ /usr/lib/atlas/* /usr/lib/openblas/*
there *.so.3 created by update-alternatives.
But which variant is better?
/usr/lib/blas/libblas.so /usr/lib/blas/libblas.so.3 /usr/lib/blas/libblas.so.3.5.0
or
/usr/lib/libblas.so
definitely /usr/lib/libblas.so
/usr/lib/blas/libblas.so.3.5.0
Looks like there is no conflict between -devel packages.
Right, they don't share library names. It's also not necessary to have /usr/lib/atlas/* - only /usr/lib/lapack and /usr/lib/blas are necessary because those create the conflict with the alternatives link.
Using of stub libraries is more difficult, in this case we need to patch applications.
No, you only need to patch blas/lapack implementations. But yes, symlinking is easier - if it works. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=861081 https://bugzilla.novell.com/show_bug.cgi?id=861081#c14 --- Comment #14 from Dmitry Roshchin <dmitry@roshchin.org> 2014-06-22 16:18:00 UTC --- SR#238081 will fix it (https://build.opensuse.org/request/show/238081). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=861081 https://bugzilla.novell.com/show_bug.cgi?id=861081#c15 --- Comment #15 from Bernhard Wiedemann <bwiedemann@suse.com> 2014-06-23 10:00:14 CEST --- This is an autogenerated message for OBS integration: This bug (861081) was mentioned in https://build.opensuse.org/request/show/238325 Factory / lapack -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=861081 https://bugzilla.novell.com/show_bug.cgi?id=861081#c16 --- Comment #16 from Bernhard Wiedemann <bwiedemann@suse.com> 2014-06-24 08:00:13 CEST --- This is an autogenerated message for OBS integration: This bug (861081) was mentioned in https://build.opensuse.org/request/show/238452 13.1+12.3 / lapack -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=861081 https://bugzilla.novell.com/show_bug.cgi?id=861081#c17 Matthias Grießmeier <mgriessmeier@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #17 from Matthias Grießmeier <mgriessmeier@suse.com> 2014-07-02 09:15:51 UTC --- Update released for openSUSE 12.3 and 13.1 - resolved fixed -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com