Skip to content

[R-pkg-devel] Build process generated non-portable files

2 messages · Ivan Krylov, @@j5xsj9 m@iii@g oii @iiiy@@ddy@io

Original
Ivan Krylov
# 
? Thu, 15 Aug 2024 18:58:41 +0000
anj5xsj9 at nilly.addy.io ?????:
This may be worth reporting to the rhub developers. The error is really
strange. It looks like the package at
https://github.com/cran/igraph/releases/download/2.0.3/igraph_2.0.3_b1_R4.5_x86_64-pc-linux-gnu-fedora-38.tar.gz
(referenced from https://github.com/r-hub/repos) has a binary
dependency on OpenBLAS:

$ readelf -d igraph/libs/igraph.so | grep openblas
0x0000000000000001 (NEEDED) Shared library: [libopenblasp.so.0]

...but that's either not noted or not installed correctly.
If you'd like to dig deeper, feel free to ask here with details.
Thank you for letting us know!
I experimented with the "ghcr.io/r-hub/containers/intel:latest"
container and was able to find out that the option -[no]gen-interfaces
controls the generation of *__genmod* files:

/opt/intel/oneapi/compiler/latest/bin/ifx -O3 -fp-model precise \
 -warn all,noexternals -c -o arpack/dgetv0.o arpack/dgetv0.f; \
 ls *genmod*
#  ...
# dgetv0__genmod.f90  dgetv0__genmod.mod
rm -vf *genmod*
# removed 'dgetv0__genmod.f90'
# removed 'dgetv0__genmod.mod'
/opt/intel/oneapi/compiler/latest/bin/ifx -nogen-interfaces -O3 \
 -fp-model precise -warn all,noexternals -c -o arpack/dgetv0.o \
 arpack/dgetv0.f; \
 ls *genmod*
#  ...
# ls: cannot access '*genmod*': No such file or directory

This option is already used as part of the "Intel" additional checks
performed by Prof. Brian D. Ripley, so the *__genmod.* files should not
be a problem on CRAN:
https://svn.r-project.org/R-dev-web/trunk/CRAN/QA/BDR/gannet/Intel/config.site
@@j5xsj9 m@iii@g oii @iiiy@@ddy@io
# 
I locally ran the rhub intel docker and that was much easier to set up. So I can now confirm the change to Makevars does work.
You are right. I temporarily removed the changes to Makevar and added the `-nogen-interfaces` flag to FFLAGS and that also prevented the warning. I can open an issue at rhub and suggest adding that as a default for the intel compilers.
The strange thing is the intel container on github actions has succeeded in the past but now is consistently failing to build `targets`:
Which is related to the igraph issue you mentioned. Checking the packages installed in a previous successful intel action, targets was not listed. I don't know why it's being installed now but not previously, I haven't changed dependencies.

In the past other packages have failed to build and not only on the intel container see "https://github.com/SpeakEasy-2/speakeasyR/actions/runs/10202337528/job/28226219457" where several containers failed at the setup-deps step. There is overlap in which package fails (i.e. protGenerics and sparseArray fail in multiple containers but succeed in others while in one container ExperimentHub fails). It seems the only packages failing are from Bioconductor. Assume this is a bioconductor or pak issue.

The issue with igraph is interesting though since I do use the igraph package for some examples and inside the intel container, R CMD build has no problem running igraph. Inspecting the resulting tarball shows the html version of my vignette contains results that depends on running igraph code and my test using igraph succeeds with R CMD check. Yet when I run R inside the container and try to load the igraph library or run code via `igraph::` I get an error
I.e. the same error with building targets. I can raise an issue on rigraph as well.

?- David R. Connell
On Friday, August 16th, 2024 at 7:58 AM, Ivan Krylov 'ikrylov at disroot.org' wrote: