Created attachment 551880 [details] emerge-info.txt When trying to build petsc-3.10.0 it bails out during configuration with TESTING: checkLib from config.packages.BlasLapack(/var/tmp/portage/sci-mathematics/petsc-3.10.0/work/petsc-3.10.0/config/BuildSystem/config/packages/BlasLapack.py:114) ******************************************************************************* UNABLE to CONFIGURE with GIVEN OPTIONS (see configure.log for details): ------------------------------------------------------------------------------- You set a value for --with-blaslapack-lib=<lib>, but ['-lreflapack'] cannot be used ******************************************************************************* I have lapack-reference and blas-reference from science overlay installed, as well as using the virtuals for them from science overlay. artus /etc # eselect lapack list Available providers for lapack: [1] reference * artus /etc # eselect blas list Available providers for blas: [1] reference * artus /etc # pkg-config --libs lapack -lreflapack artus /etc # emerge -pqv =sci-mathematics/petsc-3.10.0::science [ebuild N ] sci-mathematics/petsc-3.10.0 USE="X boost cxx doc fftw fortran hdf5 hypre mpi mumps scotch sparse threads -afterimage -complex-scalars -debug (-metis) -superlu" Build log and emerge --info output as well as configure.log will be attached as files.
Created attachment 551882 [details] petsc-3.10.0:20181019-211630.log build log
Created attachment 551884 [details] configure.log.bz2
Its been a few months and this bug is still marked unconfirmed. I'm confirming it has hit two of my machines. This is a problem with pkg-config and lapack. It builds with 3.7 but not 3.8 With sci-libs/lapack-reference-3.8.0-r100: $ pkg-config --libs lapack -lreflapack With sci-libs/lapack-reference-3.7.0-r100: $ pkg-config --libs lapack -lreflapack -lopenblas_openmp In 3.8, the lapack.pc file makes blas private: Requires.private: blas Whereas in 3.7, the lapack.pc file makes blas private: Requires: blas making lapack.pc for 3.8 read as 3.7 allowed petsc to complete. The bigger question is where to fix it... was there a reason lapack 3.8 marked blas private? Is a workaround needed for petsc or is lapack broken. Thanks,
Hi Bernd, Thank you! Could you please test petsc against virtual/blas and virtual/lapack from the gentoo main repository? They have just been upgraded to solve these issues. You probably need to uninstall the lapack/blas from the science overlay first. Benda
Hi Benda, I can test this against the ::gentoo {blas,lapack} virtuals. I'm probably going to test this inside a clean chroot, as there's more to it than just uninstalling lapack/blas from ::science.
Hi Bernd, (In reply to Bernd from comment #5) > Hi Benda, > > I can test this against the ::gentoo {blas,lapack} virtuals. I'm probably > going to test this inside a clean chroot, as there's more to it than just > uninstalling lapack/blas from ::science. Thank you so much for offering help. You are also welcomed to test out more ebuilds inside the sci overlay for the compatibility with ::gentoo {blas,lapack} virtuals that are interesting to you. The blas,lapack framework will finally be deprecated. Before that we will need to make sure all the reverse dependencies are migrated to the one in ::gentoo. https://github.com/cdluminate/my-overlay/blob/master/usage.md is a piece of draft document to appear soon. Yours, Benda
(In reply to Benda Xu from comment #6) > Hi Bernd, > > The blas,lapack framework will finally be deprecated. I meant the one in sci overlay, aka alternative-2.eclass.
(In reply to Benda Xu from comment #6) > > The blas,lapack framework will finally be deprecated. Before that we will > need to make sure all the reverse dependencies are migrated to the one in > ::gentoo. I think it's a good thing to have this back in the main tree and with unified mechanics. I have used the alternatives-2.eclass for quite some time and there's a couple of revdeps which I have installed, although most of them are from ::gentoo, beside the core blas/lapack packages. I'm glad to help with the transition to the new framework and will probably start in the upcoming week, removing the masks for ::gentoo blas/lapack/eselect and looking what needs to be rebuilt.
(In reply to Bernd from comment #8) > (In reply to Benda Xu from comment #6) > > > > The blas,lapack framework will finally be deprecated. Before that we will > > need to make sure all the reverse dependencies are migrated to the one in > > ::gentoo. > > I think it's a good thing to have this back in the main tree and with > unified mechanics. > > I have used the alternatives-2.eclass for quite some time and there's a > couple of revdeps which I have installed, although most of them are from > ::gentoo, beside the core blas/lapack packages. > > I'm glad to help with the transition to the new framework and will probably > start in the upcoming week, removing the masks for ::gentoo > blas/lapack/eselect and looking what needs to be rebuilt. That would be great! I am looking forward to your tests. Feel free to open new bugs when you find regressions.
Benda, the ebuild still fails with a similar error: TESTING: checkLib from config.packages.BlasLapack(/var/tmp/portage/sci-mathematics/petsc-3.10.0/work/petsc-3.10.0/config/BuildSystem/config/packages/BlasLapack.py:114) ******************************************************************************* UNABLE to CONFIGURE with GIVEN OPTIONS (see configure.log for details): ------------------------------------------------------------------------------- You set a value for --with-blaslapack-lib=<lib>, but ['-llapack'] cannot be used ******************************************************************************* (chroot64) artus / # eselect lapack show lib64: reference (chroot64) artus / # eselect blas show lib64: reference (chroot64) artus / # pkg-config --libs blas -lblas (chroot64) artus / # pkg-config --libs lapack -llapack I installed blas/lapack with USE=eselect-ldso and also tried the updated petsc-3.11.1 release, with the same result. I compiled with a default USE flag setting, not the one mentioned in my initial report above, in effect I tried with USE="X cxx fortran". However, the patch from my PR at https://github.com/gentoo/sci/pull/898 is still compiling. In the meantime I also tested without having eselect-ldso enabled, but it doesn't matter, the result is the same.
Hi Matthias, I see you have updated petsc recently. Would you please look into this bug and the pull request at https://github.com/gentoo/sci/pull/898? Thanks, Benda
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/proj/sci.git/commit/?id=0b1e1d868ca34c28fcfbcb5e30d2ed0e63c94039 commit 0b1e1d868ca34c28fcfbcb5e30d2ed0e63c94039 Author: Bernd Waibel <waebbl@gmail.com> AuthorDate: 2018-11-09 16:36:54 +0000 Commit: Matthias Maier <tamiko@gentoo.org> CommitDate: 2019-07-12 10:55:21 +0000 sci-mathematics/petsc: fix blas configuration error * add blas to call to pkg-config for blas/lapack * make EAPI 7 compatible, remove versionator.eclass * change --with-cmake= variable to avoid warning Thanks to @ycoudier for hint on pkg-config Suggested-by: @ycoudier Closes: https://bugs.gentoo.org/669040 Closes: https://github.com/gentoo/sci/issues/892 Package-Manager: Portage-2.3.51, Repoman-2.3.12 Signed-off-by: Bernd Waibel <waebbl@gmail.com> Signed-off-by: Matthias Maier <tamiko@gentoo.org> sci-mathematics/petsc/petsc-3.10.0.ebuild | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-)
Thanks for the pull request. I have pushed the changes (also applied to all other 3.10* and 3.11* versions in the tree). The ebuild is currently in a bit of a sorry state - I haven't found the time for a proper cleanup (and push to ::gentoo)...
