Thanks for the great explanation, Simon, much appreciated and very helpful!
> On Jan 26, 2026, at 8:25 PM, Simon Urbanek <[email protected]> > wrote: > > > >> On 27 Jan 2026, at 10:06, John Benninghoff <[email protected]> wrote: >> >> I’ve run into this problem before as well (not finding emutls_w), and have >> done a fair amount of research on it. Some key points of what I’ve learned: >> >> R/CRAN, including the default R Makeconf assumes that you have a specific >> version/build of gfortran installed from https://mac.r-project.org/tools/: >> >> - gfortran 4.2.3 for R 3.6 (https://cran.r-project.org/bin/macosx/tools/) >> - gfortran 8.2 for intel R 4.0 through 4.2 >> (https://github.com/fxcoudert/gfortran-for-macOS) >> - gfortran 11.0.0 for arm64 R 4.1 >> (https://mac.r-project.org/libs-arm64/gfortran-f51f1da0-darwin20.0-arm64.tar.gz) >> - gfortran 12.0.1 for arm64 R 4.2 >> (https://github.com/R-macos/gcc-darwin-arm64) >> - gfortran-12.2-universal.pkg for R 4.3 and 4.4 >> (https://github.com/R-macos/gcc-12-branch) >> - gfortran-14.2-universal.pkg (r-gfortran) for R 4.5 and newer >> (https://github.com/R-macos/gcc-14-branch) >> >> If you’re using a different gfortran (for example, from Homebrew’s gcc >> formula), you’ll need a custom .R/Makevars (which you may need for other >> reasons, such as using libomp). (A copy of my Makevars is available here: >> https://github.com/jabenninghoff/macos-env/blob/master/R/Makevars). This is >> also discussed in an issue for rig: https://github.com/r-lib/rig/issues/207. >> >> What I don’t know and don’t understand is why emutls_w (or heapt_w) are >> needed, does anyone here know? In the past, I’ve been able to build R >> packages from source with a custom FLIBS that doesn’t include either >> library, although I’ve now switched to using the official R gfortran. >> > > It is part of the gcc runtime which is why gfortran pulls it in (remember > that GNU Fortran is the Fortran part from GCC 14.2, it has nothing to do with > Apple nor clang). You will see it in the gcc sources: > > libgcc/config.host: extra_parts="crt3.o crttms.o crttme.o libemutls_w.a " > > Those are the static and object parts of the compiler run-time (CRT). You may > get away with not using it if your source code happens to not generate > run-time code that requires it or if the driver you use happens to include > them anyway. > > Note that using anything other than the compiler R was configured with is > strictly unsupported, because part of the R configure step is to record the > flags necessary for the various compilers to link their run-time pieces > including crt/static ones - and all those are very specific to the exact > binary and directory layout of the compiler used. This is necessary, because > we allow linking of multiple languages (C, C++, Fortran) with one linker > call, which is normally impossible since each language has its own flags > generated by the language-specific linker invocation, so we extract that > information from the various linker drivers so that we can, e.g. tell the C++ > linker to also use Fortran flags if the linked binary needs both. It’s all > quite non-trivial, especially in the macOS setup, because we end up having to > merge both GCC (Fortran) and clang (C/C++) run-times into one linking step. > So the only way to do all this magic reliably is to make sure you use the > correct compiler which R was configured with, otherwise it’s just pure luck > if it works :P. > > Cheers, > Simon > > > >> Also, FWIW, I built a Homebrew cask to automate installation of R’s >> gfortran: >> https://github.com/jabenninghoff/homebrew-edge/blob/master/Casks/r-gfortran.rb. >> >> Thanks, >> John >> >>> On Jan 26, 2026, at 10:25 AM, Adelchi Azzalini <[email protected]> >>> wrote: >>> >>> Updating to gfortran 14.2 led to successful checking of the package. >>> Thanks, Ivan, for the effective suggestion. >>> The R version was already up to date. >>> >>> best wishes >>> Adelchi >>> >>> >>> >>> >>>> On 26 Jan 2026, at 16:01, Ivan Krylov <[email protected]> wrote: >>>> >>>> В Mon, 26 Jan 2026 15:31:59 +0100 >>>> Adelchi Azzalini <[email protected]> пишет: >>>> >>>>> It shows a long list of Fortran warning messages, many of them of the >>>>> following form: >>>>> >>>>> Warning: Possible change of value in conversion from REAL(8) to >>>>> INTEGER(4) at (1) [-Wconversion] >>>> >>>> These are also present in the compilation log for macOS on CRAN: >>>> https://www.r-project.org/nosvn/R.check/r-release-macos-x86_64/mnormt-00install.html >>>> >>>>> and finally >>>>> ld: library 'emutls_w' not found >>>>> clang: error: linker command failed with exit code 1 (use -v to see >>>>> invocation) >>>> >>>>> Since my macOS has recently been updated to version 26.2 (Tahoe) with >>>>> a corresponding update of Xcode, I wonder whether this update has >>>>> anything to do with these problems. >>>> >>>> It's probably due to the toolchain version mismatch. What's your R >>>> version? Maybe you need a newer gfortran, 14.2 instead of 12.2? >>>> See https://mac.r-project.org/tools/ for download links. >>>> >>>> -- >>>> Best regards, >>>> Ivan >>> >>> ______________________________________________ >>> [email protected] mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> >> >> [[alternative HTML version deleted]] >> >> ______________________________________________ >> [email protected] <mailto:[email protected]> mailing >> list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel [[alternative HTML version deleted]] ______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
