[R-pkg-devel] Build process generated non-portable files
I'm working on a package that uses some fortran copied from elsewhere. It compiles and build fine everywhere but exclusively in the intel environment (provided by rhub), the intel fortran compiler generates intermediary files from *.f -> *__genmod.f90. The R check then complains that the genmod files are not portable. I include removal of the files in my cleanup file so the files do not exist in the original package source or in the final source tarball but it seems the portable files check is done after compilation but before cleanup. - Is there a way to get around this complaint? - Should this complaint be here in the first place? I'm not familar with fortran but the warning message is: "Found the following files with non-portbale usage of KIND:." In "Writing R Extensions/Writing portable packages/Portable Fortran code" it mentions the use of REAL(KIND=8) types are not portable since compilers can map values to different types (and these declarations are in the f90 files), but the compiler called the preprocessing of the files so it should be correct for this specific compiler. The docs also mention the intel compiler will perform this preprocessing so this seems to be expected behavior. Shouldn't the portable files check only be performed on the shipped source code? In general, isn't it reasonable that build processes generate files specific to the environment? - David R. Connell [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Build process generated non-portable files
This seems like it should work. Unfortunately my rhub github actions is failing to get past the setup deps step which has been occuring inconsistently in the past but right now it's consistently failing to build deps so I can't confirm it work. I was also unable to successfully build R using intel compilers, even when using Rhubs container as template. > Include the first 'all' target in your Makevars I was really trying to avoid explicitly creating a target in makevars but this is simple enough. In case anyone else comes across this, the genmod files end up in `src` even if the original source files are under a subdirectory so the recipe ends up being: > -rm -f *genmod.f90 > If you manage to find an option for the ifx compiler that disables creation > of these files I installed intel compilers and checked the `ifx` man page. Could not find an option for turning off generation of the genmod files. > a brief Web search says they are for only the user to read, but most results > are from early 2010's Yeah I checked one of the files again and it does say that it's generated only for reference. - David R. Connell On Tuesday, August 13th, 2024 at 3:08 AM, Ivan Krylov 'ikrylov at disroot.org' wrote: > В Mon, 12 Aug 2024 18:24:30 + > David via R-package-devel r-package-devel@r-project.org пишет: > > > in the intel environment (provided by rhub), the intel fortran > > compiler generates intermediary files from *.f -> *__genmod.f90. The > > R check then complains that the genmod files are not portable. I > > include removal of the files in my cleanup file so the files do not > > exist in the original package source or in the final source tarball > > but it seems the portable files check is done after compilation but > > before cleanup. > > > > - Is there a way to get around this complaint? > > > Include the first 'all' target in your Makevars, make it depend on the > package shared library, and make it remove genmod files in the recipe: > > all: $(SHLIB) > -rm -f arpack/*genmod.f90 > > A similar trick is mentioned in > https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Using-Makevars. > > > - Should this complaint be here in the first place? > > > Perhaps not. If you manage to find an option for the ifx compiler that > disables creation of these files (a brief Web search says they are for > only the user to read, but most results are from early 2010's), post it > here. This may be a good argument to make this option recommended for R. > > > Shouldn't the portable files check only be performed on the shipped > > source code? > > > False negatives are possible too, in case the installation stage > (configure and/or make) performs a lot of preprocessing, or unpacks > extra sources. You could be right; I don't have statistics to back > either option as less wasteful of effort. > > -- > Best regards, > Ivan __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Build process generated non-portable files
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. > 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: 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. > 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 The strange thing is the intel container on github actions has succeeded in the past but now is consistently failing to build `targets`: > ✖ 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: ... asNamespace -> loadNamespace -> library.dynam -> > dyn.load > Execution halted > ERROR: lazy loading failed for package ‘targets’ > * removing ‘/tmp/RtmpLpWRX0/pkg-lib3c3299c227c/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 > > igraph::sample_pref(10) > Error in dyn.load(file, DLLpath = DLLpath, ...) : > unable to load shared object > '/root/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 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: > В Thu, 15 Aug 2024 18:58:41 + > anj5x...@nilly.addy.io пишет: > > > This seems like it should work. Unfortunately my rhub github actions > > is failing to get past the setup deps step which has been occuring > > inconsistently in the past but right now it's consistently failing to > > build deps so I can't confirm it work. > > > 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 > 0x0001 (NEEDED) Shared library: [libopenblasp.so.0] > > ...but that's either not noted or not installed correctly. > > > I was also unable to successfully build R using intel compilers, even > > when using Rhubs container as template. > > > If you'd like to dig deeper, feel free to ask here with details. > > > In case anyone else comes across this, the genmod files end up in > > `src` even if the original source files are under a subdirectory so > > the recipe ends up being: > > > > > -rm -f *genmod.f90 > > > Thank you for letting us know! > > > I installed intel compilers and checked the `ifx` man page. Could not > > find an option for turning off generation of the genmod files. > > > I experimented with the "ghcr.io/r-hub
