Summary: | sci-libs/suitesparseconfig-7.0.0: fails to configure (Could NOT find BLAS (missing: BLAS_LIBRARIES) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Sam James <sam> |
Component: | Current packages | Assignee: | Gentoo Science Related Packages <sci> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | b.buschinski, dennis.lissov, fabio.coatti, flow, fordfrog, frp.bissey, gentoo, heroxbd, jfostiguy, leonchik1976, mackal.cook, mail, mgorny, mjo, proteuss, th-gen, vowstar |
Priority: | Normal | Keywords: | PMASKED |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log |
Description
Sam James
2023-06-20 02:06:42 UTC
May need USE-dep on eselect-ldso for virtual? I had a report on this same problem Saturday in the sage-on-gentoo overlay and I thought the BDEPEND on virtual/blas would be enough. Do you mean we should have something like BDEPEND="virtual/blas[eselect-dso=]" ? (In reply to François Bissey from comment #2) > I had a report on this same problem Saturday in the sage-on-gentoo overlay > and I thought the BDEPEND on virtual/blas would be enough. Do you mean we > should have something like > BDEPEND="virtual/blas[eselect-dso=]" > ? sorry, I was typing it quickly from another machine: just BDEPEND="virtual/blas[eselect-dso]" is probably enough. I'll try it now. IIRC that USE flag is needed to make e.g. OpenBLAS install the library with the generic name and in the generic location. So if FindBLAS.cmake is only going to look for /usr/lib64/libblas.so, then USE=eselect-ldso will probably be necessary to put it there. It helps for native but not for multilib because blas isn't multilib... Seems like the only solution right now is to set USE="-abi_x86_32" for sci-libs/suitesparseconfig and packages depending on it. I don't like it but an alternative may be to disable detection of BLAS in suitesparseconfig (by patching) and return to the status quo of the previous ebuilds. We need to check that the shipped headers are still sane in that case. I just checked my SuiteSparse_config.h header are exactly the one shipped in tarball. They are not altered by running cmake at all it seems. So, we could go ahead with removing the detection. In the end it is not possible to remove the detection. It alters the configuration in ways that makes the compilation of libsuitesparseconfig breaks because it needs to know the size of indexing integer in blas (are we int32 or int64?). That's what the blas detection is supposed to achieve. (In reply to François Bissey from comment #8) > In the end it is not possible to remove the detection. It alters the > configuration in ways that makes the compilation of libsuitesparseconfig > breaks because it needs to know the size of indexing integer in blas (are we > int32 or int64?). That's what the blas detection is supposed to achieve. As it stands, it's never going to find BLAS for multilib, as we don't have any ebuilds providing it. I must say that I did not realise we had stopped providing multilib with the current system. I had quite a fight to get it to work properly when we had an alternative system in the science overlay. I guess that means we'll have to remove multilib from all the suitesparse ebuilds. What downstream packages would that impact? (In reply to François Bissey from comment #10) > I guess that means we'll have to remove multilib from all the suitesparse > ebuilds. What downstream packages would that impact? sci-libs/cxsparse + all the packages that were just added. After removing it from cxsparse I get no further problems, at least in ::gentoo as of f045d787a94b (i.e. just before suitesparseconfig was bumped). The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=defb93add229bb3fd038be70ed3722fe5e7477f9 commit defb93add229bb3fd038be70ed3722fe5e7477f9 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2023-06-21 03:19:52 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2023-06-21 03:22:21 +0000 package.mask: Mask =sci-libs/suitesparseconfig-7.0.0 and revdeps The =sci-libs/suitesparseconfig-7.0.0 ebuild was added with nonfunctional multilib support that causes a build failure. Since all the added ebuilds depend on the new version (and multilib support) fixing this is non-trivial. Bug: https://bugs.gentoo.org/908851 Signed-off-by: Michał Górny <mgorny@gentoo.org> profiles/package.mask | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) There are a two other bugs in bugzilla against cholmod and spqr about static libraries that I had not noticed before. In fact those two ship dummy cuda libraries (including static) if cuda is not enabled. There is an issue upstream and I am working on it. I am hoping to fix them while under mask. sci-libs/suitesparseconfig-7.0.0 could be masked on multilib profile, but not generally. on pure 64-bit install everything works perfectly. No issues whatsoever. I see absolutely NO reason to mask it. It's annoying to have a system upgrade fail, so the mask is the right thing to do for now and I'm glad to have the help. We'll get it fixed soon, even if the fix is to drop multilib support. (In reply to Sam James from comment #5) > It helps for native but not for multilib because blas isn't multilib... On Gentoo Packages I see that all the following packages are avaliable for amd64 and x86, why is those no multilib? (I'm kinda new here and is not that proficient in architecture-related stuff) Packages: virtual/blas sci-libs/lapack sci-libs/openblas sci-libs/blis OK, I am going to make a PR for suitesparse 7.3.1 - with additional packages spex and rbio (the later because of #921100). The ebuilds will have no multilib bits in them and the issues about static and dummy cuda libs being shipped are fixed. I hope we can lift the mask for that version. There is a 7.4.0 release too, and I have some ebuilds for them too in the sage-on-gentoo overlay - masked. 7.4.0 has two major new features: * a full cmake superbuild. So, we could technically replace the individual packages by a single one with a ton of useflags. * probably as a consequence of the above change, all headers are now shipped in a suitesparse folder. Which breaks absolutely every dependency hard. Which is why I masked it even in the overlay and started work towards 7.3.1. Of note, suitesparse now ships .pc files as well as .cmake files. But of course the naming is slightly different from the one we had in the 5 and under series. The names are in all caps (AMD.pc, CHOLMOD.pc...) except for "SuiteSparse_config.pc". Could not make it work with cvxopt though. Suitesparse 7.3.1 is now https://github.com/gentoo/gentoo/pull/34732 (In reply to Erina Init from comment #16) > (In reply to Sam James from comment #5) > > It helps for native but not for multilib because blas isn't multilib... > > On Gentoo Packages I see that all the following packages are avaliable for > amd64 and x86, why is those no multilib? (I'm kinda new here and is not that > proficient in architecture-related stuff) > > Packages: > virtual/blas sci-libs/lapack sci-libs/openblas sci-libs/blis (In reply to François Bissey from comment #10) > I must say that I did not realise we had stopped providing multilib with the > current system. I had quite a fight to get it to work properly when we had > an alternative system in the science overlay. > > I guess that means we'll have to remove multilib from all the suitesparse > ebuilds. What downstream packages would that impact? I decided to drop multilib on purpose back in 2020 or so, during the runtime switch of blas/lapack was introduced[1], because there were too many corner cases. I thought it did not worth the effort until I identify a use-case for the multilib. So would you inspire me when multilib is absolutely needed for numerical computation in science and engineering? Yours, Benda 1. https://wiki.gentoo.org/wiki/Blas-lapack-switch#Frequently_asked_questions |