[R-pkg-devel] Reliably detecting FLIBS on source build of R (w.r.t Rust packages)
Thank you, Simon and Ivan.? And further thanks to Ivan for R sleuthing of the first order! That I'm picking up the wrong R makes sense.? I will incorporate your suggestions Best wishes, -Naras
On 1/25/25 11:55 PM, Ivan Krylov wrote:
? Sat, 25 Jan 2025 08:54:45 -0800 Balasubramanian Narasimhan <naras at stanford.edu> ?????:
(https://github.com/blas-lapack-rs/r-src/blob/966266425b1a21a1e979f767c6023e6bf00616fc/build.rs#L160).
Thank you for providing the link to the code!
The only thing I can think of is that FLIBS is being set outside config.site or Makevars during the R build.
I think this is happening because the r-src crate is running the wrong
R executable to determine the linker flags. The check system is running
/Users/ripley/R/R-devel/bin/R, while there's also a different R (for
example, /usr/local/bin/R) visible on the $PATH. The code ends up
getting the linker flags from the latter when it runs "R" [1].
I think it should be possible to sidestep this issue altogether if you
only enable the static library at [2] and then have R link the package
shared library for you from the static library produced by Rust using
the flags you're correctly setting in Makevars [3].
If you do need Rust to determine the linker flags by itself, make sure
to run ${R_HOME}/bin/R, not just R [4].
Unrelated but probably important: having 'all' or $(SHLIB) depend on a
target that removes the files you've built [5] is a bad idea because
Make is allowed to run independent recipes in undefined order,
including rm -Rf $(SHLIB) $(STATLIB) $(OBJECTS) while $(STATLIB) is
being built [6]. Note how 'rm -Rf ...' is the first command being run
in [7], before any compilation happens. The files you're removing as
part of the $(STATLIB) recipe should be enough; there shouldn't be any
need for the 'C_clean' recipe.