r-lib / pkgbuild

Find tools needed to build R packages
https://pkgbuild.r-lib.org
Other
65 stars 33 forks source link

No compiler found + no ability to fork. ¿Related issues? #138

Closed xfim closed 2 years ago

xfim commented 2 years ago

Hello,

I am a bit puzzled by the current situation of my R install (GNU/Linux), that was perfectly working last week. I have, I would say, two "manifestations" of what is probably the same problem, but at this point I am not so sure.

The first manifestation was the inability to use devtools::check(). The system complains that it is not possible to fork. I thought I was dealing with a processx package problem, and so I opened this issue: https://github.com/r-lib/processx/issues/336

But the more I dig onto it, the closer it gets to pkgbuild: it turns out I don't seem to have a compiler:

> pkgbuild::has_compiler(debug = TRUE)
Trying to compile a simple C file
Running /usr/lib64/R/bin/R CMD SHLIB foo.c
[1] FALSE

Although I can compile several packages normally

So far I have tried:

I can't try it with install_github() because it fails due to the inability to fork:

> devtools::install_github("r-lib/pkgbuild") 
Downloading GitHub repo r-lib/pkgbuild@HEAD
Error: Failed to install 'pkgbuild' from GitHub:
  Cannot fork when running '/usr/lib64/R/bin/R' (system error -12, Error desconegut -12) @unix/processx.c:533 (processx_exec)                    

So my issue is, first, whether this is really related to pkgbuild; second, is there a bug somewhere and third, what can I do to solve it.

Thank you very much for your support.

gaborcsardi commented 2 years ago

I don't think there were any changes in pkgbuild or processx that could cause this. What is the output of sessioninfo::session_info() or sessionInfo()? What is your compiler version? What OS is this?

Btw. you don't need pkgbuild to install packages from GitHub, you can try to use pak:

pak::pkg_install("r-lib/pkgbuild")

or remotes without pkgbuild:

Sys.setenv("R_REMOTES_STANDALONE" = "true")
remotes::install_github("r-lib/pkgbuild")
xfim commented 2 years ago

Thank you for your suggestions, @gaborcsardi .

I am working from a Gentoo GNU/Linux machine, using gcc-11.2.1:

 sessionInfo()
R version 4.2.0 (2022-04-22)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Gentoo/Linux

Matrix products: default
BLAS:   /usr/lib64/blas/openblas/libblas.so.3
LAPACK: /usr/lib64/libopenblasp-r0.3.20.so

locale:
 [1] LC_CTYPE=ca_AD.UTF-8       LC_NUMERIC=C
 [3] LC_TIME=ca_AD.UTF-8        LC_COLLATE=ca_AD.UTF-8
 [5] LC_MONETARY=ca_AD.UTF-8    LC_MESSAGES=ca_AD.UTF-8
 [7] LC_PAPER=ca_AD.UTF-8       LC_NAME=C
 [9] LC_ADDRESS=C               LC_TELEPHONE=C
[11] LC_MEASUREMENT=ca_AD.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

loaded via a namespace (and not attached):
 [1] processx_3.5.3 compiler_4.2.0 R6_2.5.1       cli_3.3.0      tools_4.2.0
 [6] glue_1.6.2     callr_3.7.0    ps_1.7.0       pak_0.3.0      tcltk_4.2.0

As for your suggestion of using pak, it seems to be yet another manifestation of the same problem:

> pak::pkg_install("r-lib/pkgbuild")
Error in rethrow_call(c_processx_exec, command, c(command, args), pty,  :
  Cannot fork when running '/usr/lib64/R/bin/R' (system error -12, Error desconegut -12) @unix/processx.c:533 (processx_exec)

But interestingly, your suggestion to use remotes works:

> Sys.setenv("R_REMOTES_STANDALONE" = "true")
> remotes::install_github("r-lib/pkgbuild")
Downloading GitHub repo r-lib/pkgbuild@HEAD
Running `R CMD build`...
* checking for file ‘/tmp/Rtmp9BoBdy/remotes7c5a519bb090/r-lib-pkgbuild-a22b6a3/DESCRIPTION’ ... OK
* preparing ‘pkgbuild’:
* checking DESCRIPTION meta-information ... OK
* checking for LF line-endings in source and make files and shell scripts
* checking for empty or unneeded directories
* building ‘pkgbuild_1.3.1.9000.tar.gz’
* installing *source* package ‘pkgbuild’ ...
** using staged installation
** R
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded from temporary location
** testing if installed package can be loaded from final location
** testing if installed package keeps a record of temporary installation path
* DONE (pkgbuild)

(although after loading the development version the problem still persists).

For me this indicates some sort of trouble with non-remotes family, isn't it? Any other hint?

Thank you very much for your support.

gaborcsardi commented 2 years ago

This seems like a memory error, the error is probably wrong and not -12 but 12, which is "Cannot allocate memory.". I don't think this is likely the problem, but does your system have enough memory?

I am fairly sure that this error is specific to Gentoo or even more likely, to your installation, which means that it is not easy to help you with it. I just installed gentoo in Docker, and then R 4.0.5 (that's the default version for some reason), and everything works fine.

I know it is a lot to ask, but if you could create a self-contained Docker container that illustrates the issue, then I could debug this.

xfim commented 2 years ago

OK, thank you again @gaborcsardi .

I have not even considered memory issues here. First, because I've been using pkgbuild in the past with any troubles, and second because this light installation and the state of the machine does not suggest that this should be it.

Also, because for the small compilation of the foo.c, that does not find the compiler. (BTW, do you think these are related issues?)

> pkgbuild::has_compiler(debug = TRUE)
Trying to compile a simple C file
Running /usr/lib64/R/bin/R CMD SHLIB foo.c
[1] FALSE

As for the docker, I can try to adapt this: https://hub.docker.com/repository/docker/xfim/sci-bayes

I will let you know when I am done.

xfim commented 2 years ago

Dear @gaborcsardi ,

Sorry to bother again with this. I am still tracing it while the docker image is being processed.

I have traced that pkgbuild::has_compiler() calls callr::rcmd_safe(). Then, going to the examples of callr, the first one fails with basically the same error:

> library(callr)
> r(function() var(iris[, 1:4]))
Error in rethrow_call(c_processx_exec, command, c(command, args), pty,  :
  Cannot fork when running '/usr/lib64/R/bin/R' (system error -12, Error desconegut -12) @unix/processx.c:533 (processx_exec)
Type .Last.error.trace to see where the error occurred
> .Last.error.trace

 Stack trace:

 1. callr:::r(function() var(iris[, 1:4]))
 2. callr:::run_r(options)
 3. base:::with(options, with_envvar(env, do.call(processx::run,  ...
 4. base:::with.default(options, with_envvar(env, do.call(processx::run,  ...
 5. base:::eval(substitute(expr), data, enclos = parent.frame())
 6. base:::eval(substitute(expr), data, enclos = parent.frame())
 7. callr:::with_envvar(env, do.call(processx::run, c(list(bin, args = real_cmd ...
 8. base:::force(code)
 9. base:::do.call(processx::run, c(list(bin, args = real_cmdargs,  ...
 10. (function (command = NULL, args = character(), error_on_status = TRUE,  ...
 11. process$new(command, args, echo_cmd = echo_cmd, wd = wd, windows_verbatim_a ...
 12. processx:::initialize(...)
 13. processx:::process_initialize(self, private, command, args, stdin,  ...
 14. rethrow_call(c_processx_exec, command, c(command, args), pty,  ...

 x Cannot fork when running '/usr/lib64/R/bin/R' (system error -12, Error desconegut -12) @unix/processx.c:533 (processx_exec)

Yet another "cannot fork" problem. And in this case there is no memory involved, not compilation, an easy call to var().

May it be something along the line of not being able to create sub-processess? Any thoughts? Hints? I'll let you know anyway.

Thank you again.

xfim commented 2 years ago

Dear @gaborcsardi ,

I still don't really know the source of the problem. But after recompiling blis, openblas, and R again, there are no more problems. R finds a compiler, devtools can check, etc... So this leaves me to think that it was somehow related to them, not to pkgbuild, neither processx. I am sorry for all the trouble.

I have, however, updated the docker container with a working installation of R in Gentoo, in case you want to try it, or is useful at some point: https://hub.docker.com/repository/docker/xfim/sci-bayes.

docker push xfim/sci-bayes:v1.2