[R-pkg-devel] Reliably detecting FLIBS on source build of R (w.r.t Rust packages)

[Balasubramanian Narasimhan]

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 using 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.
>