Closed DavidRConnell closed 3 months ago
An obvious workaround would be to stop using that repo, but building all packages from source takes a very long time.
So it is better to simply install openblas on that computer. Packages built from source will still link to MKL, as they should, but the generic Fedora binaries should keep working then.
Closed by https://github.com/r-hub/containers/commit/0da00348a7501d92b0d940f13064eb7afb5c7e92
Will be fixed in tomorrow's builds.
Thanks. Does this mean that the binary packages on Fedora don't (and can't) link to MKL OpenBLAS because they must work in environments where that is not available? Is there anything we should fix in the igraph build system?
AFAIR there is a way to set up R, so that packages link to an R LAPACK/BLAS wrapper, and then those binary packages should be more portable. The binary binary packages from https://github.com/r-hub/repos#fedora-38--r-devel-fedora-38-r45 apparently link to BLAS/LAPACK directly.
I was the one originally bringing up the question why it's not linking to the BLAS/LAPACK wrappers, like it does when using CRAN's R. So it seems that this is outside of the control of igraph, and depends on the R distribution. Therefore we don't need to fix anything in the igraph build system. I'm spelling this out just to confirm my understanding.
pak in the intel container uses the fedora 38 repo. The precompiled igraph package in this repo depends on openblas when it should use mkl. This prevents igraph from being loaded in R, which causes errors building dependencies such as:
The igraph R package can be built in the intel container in which case it is not dependent on openblas.
CRAN does not release a version of igraph built using intel compilers so it may be necessary to force igraph to be built from source in the intel container if there's a way to do that without messing up how the r-hub/repo works in other containers.