> 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] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
