igraph depends on openblas in intel environment

[DavidRConnell]

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:

  ✖ Failed to build targets 1.7.1 (2.1s)
  Error:
  ! error in pak subprocess
  Caused by error in `stop_task_build(state, worker)`:
  ! Failed to build source package targets.
  Full installation output:
  * installing *source* package ‘targets’ ...
  ** package ‘targets’ successfully unpacked and MD5 sums checked
  staged installation is only possible with locking
  ** using non-staged installation
  ** R
  ** inst
  ** byte-compile and prepare package for lazy loading
  Error in dyn.load(file, DLLpath = DLLpath, ...) :
    unable to load shared object '/github/home/R/x86_64-pc-linux-gnu-library/4.5/igraph/libs/igraph.so':
    libopenblasp.so.0: cannot open shared object file: No such file or directory
  Calls: <Anonymous> ... asNamespace -> loadNamespace -> library.dynam -> dyn.load
  Execution halted
  ERROR: lazy loading failed for package ‘targets’
  * removing ‘/tmp/RtmpEH9rmv/pkg-lib3c55ef3cd91/targets’
  ---
  Backtrace:
  1. pak::lockfile_install(".github/pkg.lock")
  2. pak:::remote(function(...) { …
  3. err$throw(res$error)
  ---
  Subprocess backtrace:
   1. base::withCallingHandlers(cli_message = function(msg) { …
   2. get("lockfile_install_internal", asNamespace("pak"))(...)
   3. plan$install()
   4. pkgdepends::install_package_plan(plan, lib = private$library, num_workers = nw, …
   5. base::withCallingHandlers({ …
   6. pkgdepends:::handle_events(state, events)
   7. pkgdepends:::handle_event(state, i)
   8. pkgdepends:::stop_task(state, worker)
   9. pkgdepends:::stop_task_build(state, worker)
  10. base::throw(pkg_error("Failed to build source package {.pkg {pkg}}.", …
  11. | base::signalCondition(cond)
  12. global (function (e) …
  Execution halted
  Error: Process completed with exit code 1.

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.

[gaborcsardi]

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.

[gaborcsardi]

Closed by r-hub/containers@0da0034

Will be fixed in tomorrow's builds.

[krlmlr]

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?

[gaborcsardi]

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.

[szhorvat]

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.