gfortran FLIBS search path hard coded and pointed to the wrong directory on recent installs

[danielloader]

Reproduction steps:

• MacOS 14.2
• M1 Pro 32GB
• R 4.1.3

brew tap r-lib/rig && brew install --cask rig
rig install 4.1
rig default 4.1-arm64
rig system add-pak
rig sysreqs add gfortran
R -e 'install.packages("actuar")'

This yields:

...
ld: warning: -single_module is obsolete
ld: warning: -multiply_defined is obsolete
ld: warning: search path '/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.2.0/11.0.0' not found
ld: library 'emutls_w' not found
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [actuar.so] Error 1
ERROR: compilation failed for package ‘actuar’
* removing ‘/Users/daniel.loader/Library/R/arm64/4.1/library/actuar’

The downloaded source packages are in
        ‘/private/var/folders/lc/vp81kbqj7551cb12tfb3wqqm0000gn/T/RtmpYRZziz/downloaded_packages’
Warning message:
In install.packages("actuar") :
  installation of package ‘actuar’ had non-zero exit status

$ R CMD config FLIBS
-L/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.2.0/11.0.0 -L/opt/R/arm64/gfortran/lib -lgfortran -lemutls_w -lm

Setting ~/.R/Makevars to the following fixes it:

FLIBS =  -L/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.6.0/12.0.1 -L/opt/R/arm64/gfortran/lib -lgfortran -lemutls_w -lm

So my question is, where is the disconnect here and where is the FLIBS variable being set by rig when it installs R 4.1.3?

While I'm okay with having my own overrides in my home directory, however it's not a good onboarding experience for new devs in future for them to have to look in /opt/R/arm64/gfortran and try and work out the directory versions, and then override them as it's likely to change in future.

Is this something rig can resolve so the default install steps work without needing a custom Makevars file?

[gaborcsardi]

rig does not set FLIBS, all it does is installing gfortran. Unfortunately this is a bit cumbersome to set up, the R config has hardcoded paths. I hope we can make it easier in the future. Right now this fixed it for me:

sudo ln -sf /opt/gfortran/SDK /Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk
sudo mkdir /opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.2.0/
sudo ln -s /opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.6.0/12.0.1 /opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.2.0/11.0.0

[danielloader]

That's great. That does work for me too.

Is it worth keeping this issue opened and close it if we can automate this somehow in future?

[gaborcsardi]

Yeah, let's keep it open. Unfortunately it is pretty hard to automate things for multiple R versions, gfortran versions, arm64 and x86_64, etc. But I am planning to take a thorough look at least.

[danielloader]

Maybe a compromise is an interactive guided command that shows you the versions available and creates the symlink or something. I know it's not the solution but it's a step up from guessing the path to symlink both from and to.

[gaborcsardi]

Oh, you don't need to guess. This is where R is looking for it:

❯ R-4.1-arm64 CMD config FLIBS
-L/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.2.0/11.0.0 -L/opt/R/arm64/gfortran/lib -lgfortran -lemutls_w -lm

and you link it to the one that you have installed. Similarly to /opt/gfortran/SDK which needs to point to an SDK according to the R docs.

The complications start when you install multiple R versions, and they need different gfortran versions, etc.

[jabenninghoff]

I've been researching this issue myself, and found that setting the following in ~/.R/Makevars also fixes the issue:

FLIBS=-L/opt/R/arm64/gfortran/lib -lgfortran -lm

I haven't been able to find a package that fails to compile without -lemutls_w.

What I've learned so far:

1. libemutls_w.a is only found in the platform-specific library directory (/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.6.0/12.0.1/)
2. emutls provides thread-level storage emulation. According to Stack Overflow, Apple added thread local support in clang starting in Xcode 8 (2016)

So... it seems likely to me that-lemutls_w was needed in the past, but is no longer needed for currently supported versions of macOS. What I can't figure out is why R thinks it's still needed.