Created attachment 368108 [details] sci-libs/lapackpp-2.5.4-build.log showing no blas or lapack installed Working with the [science] overlay, I've installed app-admin/eselect-1.4-r100::science, sci-libs/atlas-3.10.1-r1::science, sci-libs/openblas-0.2.8::science, sci-libs/gsl-1.16-r1::science, & sci-libs/lapackpp-2.5.4::science. The problem I ran into lyes with app-admin/eselect-blas, app-admin/eselect-cblas, & eselect-lapack not being ported to the [science] overlay. Attempting to emerge new eselect-[c]blas/lapack from the main portage trunk shows atlas-3.10-r1 as blocking and wishes to uninstall. But atlas-3.10.1-r1 is not a blocked package in [science]. I still have the original eselect modules for [c]blas/lapack & was working unaware until recently when a @world pass stopped at sci-libs/lapackpp-2.5.4, crying that no blas or lapack could be found or defined. Closing inspection showed random switching between active blas and lapack implementations after some re compiles, and well as on reboot. Also the is no gsl listing under lapack. I am posting the build.log for the failed lapackpp-2.5.4, but I think the problem is with app-admin/eselect-1.4-r100 not porting the blas modules over to [science]
Your build.log says --with-blas=-lf77blas --with-lapack=-latllapack -lf77blas -latlcblas which clearly indicates that blas and lapack are set correctly.
Could you please check whether you have /usr/lib(64)/libblas.so /usr/lib(64)/liblapack.so installed on your system?
(In reply to Justin Lecher from comment #2) > Could you please check whether you have > > /usr/lib(64)/libblas.so > /usr/lib(64)/liblapack.so > > installed on your system? No, those files are not present on the machine. Also, after you pointed out where to look, I'm able to confirm the same results with sci-libs/openblas-0.2.8::science and sci-libs/lapack-reference-3.4.2::science. sci-libs/gsl-1.16-r1::science isn't an option for lapack anymore, so my original bug for eselect was wrong. My apologizes...but let me know if you need any other build-info for sci-libs/lapackpp-2.5.4
(In reply to Jason Mours from comment #3) > (In reply to Justin Lecher from comment #2) > > Could you please check whether you have > > > > /usr/lib(64)/libblas.so > > /usr/lib(64)/liblapack.so > > > > installed on your system? > > No, those files are not present on the machine. Also, after you pointed out > where to look, I'm able to confirm the same results with > sci-libs/openblas-0.2.8::science and > sci-libs/lapack-reference-3.4.2::science. sci-libs/gsl-1.16-r1::science > isn't an option for lapack anymore, so my original bug for eselect was > wrong. My apologizes...but let me know if you need any other build-info for > sci-libs/lapackpp-2.5.4 Once again...I was looking somewhere else. Those files ARE on this machine. Thanks!
So I assume things are working fine now?
(In reply to Justin Lecher from comment #5) > So I assume things are working fine now? No... that was my eselect issue, which does not remain static & switches blas/cblas/lapack after recompiling blas, either openblas or atlas, mostly atlas.& I did not know gsl was not a supported lapack anymore. So I apologize for being confusing. But since you changed the bug over to sci-libs/lapackpp-2.5.4, this package is still broken, and does NOT compile. I've tried to re-emerge with openblas & lapack-reference and was able to reproduce the environment. As you pointing out, containing '--with-blas-flopenblas' clarifying that eselect is still making blas/cblas/lapack changes to the systems' environment. So to reopen the bug for sci-libs/lapackpp-2.5.4, I will attach the emerge info.
Created attachment 368268 [details] emerge-info
please attach /var/tmp/portage/sci-libs/lapackpp-2.5.4/work/lapackpp-2.5.4/config.log
Created attachment 368372 [details] config.log sorry this took a min.
There is something wrong with your stuff. Did you use USE=threads for atlas?
(In reply to Justin Lecher from comment #10) > There is something wrong with your stuff. Did you use USE=threads for atlas? Ok... I had threads build in atlas, but I have removed them after porting and am roughly 8 compiles in. This gentoo I'm porting is from an older box and so there is a blas trace of the old machine ,so I am 'morphing' the blas into the new machine, & will take roughly 25 compiles. Re compiles are taking roughly 8-15hrs on an 8-coreFX@4.4Ghz. So it's doing alot. But your reaction to the config.log is what lead my initial hunch that the environment wasn't set right. Maybe the problem is with atlas?
(In reply to Jason Mours from comment #11) > environment wasn't set right. Maybe the problem is with atlas? We had a problem with atlas and USE=-threads today. That was the reason for my question. The best would be if your could try to emerge blas/lapack-reference and eselect that and try again.
(In reply to Justin Lecher from comment #12) > (In reply to Jason Mours from comment #11) > > environment wasn't set right. Maybe the problem is with atlas? > > We had a problem with atlas and USE=-threads today. That was the reason for > my question. > > The best would be if your could try to emerge blas/lapack-reference and > eselect that and try again. At first, re-emerging lapack-reference produced, orphaned files: #/usr/lib64/libblas.so #/usr/lib64/pkgconfig/blas.pc So I moved the files and re-emerged lapack-reference successfully. Now attempts to change my blas: # eselect blas set -3 !!! Error: Refusing to overwrite /usr/lib64/pkgconfig/blas.pc: is not a symlink (use --force to override) !!! Error: Could not set provider reference for alternative blas: see previous errors Call stack: * do_set (alternatives.bash:301) * check_do (core.bash:24) * do_action (core.bash:105) * main (eselect:178) exiting : Using --force I was able to re-link blas and found the problem is with atlas. sci-libs/lapackpp-2.5.4 now builds fine with openblas & reference as well as reference & reference. sci-libs/lapackpp-2.5.4 still does not build with sci-libs/atlas-3.10.1-r1 set as either blas or lapack.
(In reply to Jason Mours from comment #13) > (In reply to Justin Lecher from comment #12) > > (In reply to Jason Mours from comment #11) > > > environment wasn't set right. Maybe the problem is with atlas? > > > > We had a problem with atlas and USE=-threads today. That was the reason for > > my question. > > > > The best would be if your could try to emerge blas/lapack-reference and > > eselect that and try again. > > At first, re-emerging lapack-reference produced, orphaned files: > > #/usr/lib64/libblas.so > #/usr/lib64/pkgconfig/blas.pc > Not that problem again. That's a tell tale sign that you didn't have a blas properly eselected. http://www.mail-archive.com/gentoo-science@lists.gentoo.org/msg01830.html and http://www.mail-archive.com/gentoo-science@lists.gentoo.org/msg01831.html for an explanation of what happens. So please emerge and eselect blas-reference then emerge lapack-reference.
(In reply to Francois Bissey from comment #14) > (In reply to Jason Mours from comment #13) > > (In reply to Justin Lecher from comment #12) > > > (In reply to Jason Mours from comment #11) > > > > environment wasn't set right. Maybe the problem is with atlas? > > > > > > We had a problem with atlas and USE=-threads today. That was the reason for > > > my question. > > > > > > The best would be if your could try to emerge blas/lapack-reference and > > > eselect that and try again. > > > > At first, re-emerging lapack-reference produced, orphaned files: > > > > #/usr/lib64/libblas.so > > #/usr/lib64/pkgconfig/blas.pc > > > Not that problem again. That's a tell tale sign that you didn't have a blas > properly eselected. > http://www.mail-archive.com/gentoo-science@lists.gentoo.org/msg01830.html > > and > http://www.mail-archive.com/gentoo-science@lists.gentoo.org/msg01831.html > for an explanation of what happens. > > So please emerge and eselect blas-reference then emerge lapack-reference. Doing so produced another orphaned #/usr/lib64/pkconfig/blas.pc after re-emerging blas-reference and lapack-reference with reference eseleceted. I corrected the symlink, but today after atlas remerged eselected blas/lapack as atlas the environment was set back to openblas/reference, as described.
(In reply to Jason Mours from comment #15) > (In reply to Francois Bissey from comment #14) > > (In reply to Jason Mours from comment #13) > > > (In reply to Justin Lecher from comment #12) > > > > (In reply to Jason Mours from comment #11) > > > > > environment wasn't set right. Maybe the problem is with atlas? > > > > > > > > We had a problem with atlas and USE=-threads today. That was the reason for > > > > my question. > > > > > > > > The best would be if your could try to emerge blas/lapack-reference and > > > > eselect that and try again. > > > > > > At first, re-emerging lapack-reference produced, orphaned files: > > > > > > #/usr/lib64/libblas.so > > > #/usr/lib64/pkgconfig/blas.pc > > > > > Not that problem again. That's a tell tale sign that you didn't have a blas > > properly eselected. > > http://www.mail-archive.com/gentoo-science@lists.gentoo.org/msg01830.html > > > > and > > http://www.mail-archive.com/gentoo-science@lists.gentoo.org/msg01831.html > > for an explanation of what happens. > > > > So please emerge and eselect blas-reference then emerge lapack-reference. > > Doing so produced another orphaned #/usr/lib64/pkconfig/blas.pc after > re-emerging blas-reference and lapack-reference with reference eseleceted. I > corrected the symlink, but today after atlas remerged eselected blas/lapack > as atlas the environment was set back to openblas/reference, as described. I might also be of note that the problem appears to be only with atlas, emerging openblas does not reset eselected blas/lapack environment. Unless openblas is corrupting #/usr/lib64/pkconfig/blas.pc
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5f8a985b71b033d7a7c4d252c00dd83669ee5913 commit 5f8a985b71b033d7a7c4d252c00dd83669ee5913 Author: Mo Zhou <cdluminate@gmail.com> AuthorDate: 2019-06-26 02:27:40 +0000 Commit: Benda Xu <heroxbd@gentoo.org> CommitDate: 2019-06-26 06:06:09 +0000 virtual/{blas,cblas,lapack,lapacke}: add/update virtual packages. These virtual packages are used by the BLAS/LAPACK runtime switching mechanism. Drop old EAPI=5 ebuilds. Closes: https://github.com/gentoo/gentoo/pull/12323 Closes: https://bugs.gentoo.org/373613 Closes: https://bugs.gentoo.org/669644 Closes: https://bugs.gentoo.org/564546 Closes: https://bugs.gentoo.org/565776 Closes: https://bugs.gentoo.org/646316 Closes: https://bugs.gentoo.org/563674 Closes: https://bugs.gentoo.org/659014 Closes: https://bugs.gentoo.org/659264 Closes: https://bugs.gentoo.org/657984 Closes: https://bugs.gentoo.org/381801 Closes: https://bugs.gentoo.org/646316 Closes: https://bugs.gentoo.org/565776 Closes: https://bugs.gentoo.org/498490 Signed-off-by: Mo Zhou <cdluminate@gmail.com> Signed-off-by: Benda Xu <heroxbd@gentoo.org> virtual/blas/blas-1.0.ebuild | 14 -------------- virtual/blas/blas-3.8.ebuild | 14 ++++++++++++++ virtual/blas/metadata.xml | 10 +++++++--- virtual/cblas/cblas-1.0.ebuild | 14 -------------- virtual/cblas/cblas-3.8.ebuild | 14 ++++++++++++++ virtual/cblas/metadata.xml | 10 +++++++--- virtual/lapack/lapack-3.0.ebuild | 13 ------------- virtual/lapack/lapack-3.1.ebuild | 13 ------------- virtual/lapack/lapack-3.8.ebuild | 14 ++++++++++++++ virtual/lapack/metadata.xml | 10 +++++++--- virtual/lapacke/lapacke-3.8.ebuild | 14 ++++++++++++++ virtual/lapacke/metadata.xml | 16 ++++++++++++++++ 12 files changed, 93 insertions(+), 63 deletions(-)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0721aba4db4bc8ce37d11eab06ff528f31e4ce9f commit 0721aba4db4bc8ce37d11eab06ff528f31e4ce9f Author: Benda Xu <heroxbd@gentoo.org> AuthorDate: 2019-06-27 05:41:31 +0000 Commit: Benda Xu <heroxbd@gentoo.org> CommitDate: 2019-07-03 12:30:39 +0000 virtual/{blas,cblas,lapack,lapacke}: add virtual packages. These virtual packages are used by the BLAS/LAPACK runtime switching mechanism. Closes: https://github.com/gentoo/gentoo/pull/12323 Closes: https://bugs.gentoo.org/373613 Closes: https://bugs.gentoo.org/381801 Closes: https://bugs.gentoo.org/498490 Closes: https://bugs.gentoo.org/563674 Closes: https://bugs.gentoo.org/564546 Closes: https://bugs.gentoo.org/565776 Closes: https://bugs.gentoo.org/646316 Closes: https://bugs.gentoo.org/657984 Closes: https://bugs.gentoo.org/659014 Closes: https://bugs.gentoo.org/659264 Closes: https://bugs.gentoo.org/669644 Signed-off-by: Mo Zhou <cdluminate@gmail.com> Signed-off-by: Benda Xu <heroxbd@gentoo.org> virtual/blas/blas-3.8.ebuild | 14 ++++++++++++++ virtual/blas/metadata.xml | 10 +++++++--- virtual/cblas/cblas-3.8.ebuild | 14 ++++++++++++++ virtual/cblas/metadata.xml | 10 +++++++--- virtual/lapack/lapack-3.8.ebuild | 14 ++++++++++++++ virtual/lapack/metadata.xml | 10 +++++++--- virtual/lapacke/lapacke-3.8.ebuild | 14 ++++++++++++++ virtual/lapacke/metadata.xml | 16 ++++++++++++++++ 8 files changed, 93 insertions(+), 9 deletions(-)
