Skip to content
Prev 14873 / 15075 Next

R/compilers can't find libintl.h on MacOS X

Thanks Simon, some comments to selected aspects
That's what Homebrew installs (now? perhaps it was different in the
past?), I didn't install R by hand and certainly got this R from
Homebrew, and reading the ruby script it runs, it is grabbing the
latest binary from CRAN.

I think in the short term I'll try this route of renaming
/opt/homebrew out of the way temporarily just to get working again
with mgcv.
The CRAN binary certainly doesn't work with omp out of the box on Mac
(Note, this is using the package shipped with R, not the one I was
trying to compile, and I just nuked mgcv on my system and reinstalled
from the CRAN binary to the same effect):
[1] FALSE

OpenMP is the way Simon enables parallel computation of GAMs in
`gam()` and `bam()` - which is kind of the point of at least `bam()`.

./src/Makevars does have

PKG_LIBS =  $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) $(SHLIB_OPENMP_CFLAGS)
PKG_CFLAGS = $(SHLIB_OPENMP_CFLAGS)

which includes openMP-related things, but this seemingly(?) isn't
sufficient to get it to work on MacOS X as with the CRAN binary of
mgcv's test for working omp returns FALSE, and mgcv never uses more
than a single thread - which is why I was trying to compile the
package myself in the first place. FWIW, glmmTMB::omp_check() is also
`FALSE` on my machine, so something seems to be off broadly.

I'll email Simon after investigating how data.table does things so I
have something concrete to suggest to him - that said enabling openmp
seems very convoluted if the configure script in data.table is
anything to go by, which I presume is important because even though
*I* don't need to do very much on my computer to enable compilation
using openmp, getting it to work on other systems seems decidedly
non-trivial in general.

I was perhaps operating under the false assumption that openMP wasn't
supported *at all* on Mac because of the issue with Apple's clang -
which is why I went down this route in the first place.

Going entirely with CRAN's R for Mac seems to resign a user to having
to manage the rest of their software on their machine by hand. If I
understand correctly then, I'm likely to run into problems using
CRAN's R binary alongside a package I compile manually using libraries
I have installed via homebrew (i.e. gettext, which I note in homebrew
is a couple of versions ahead of the one in your recipes, even if it
is the same gnu gettext)?

This is not meant as a complaint; I am very grateful that the binaries
exist - it has been quite the revelation from my decades on Linux
where I endured hours of update time at each new R release recompiling
all the R packages I had been using.

I am however revealing my naivety regarding the Mac platform and
trying to understand what is best for me longer-term - I really don't
want to have to manually install and maintain all the other software I
need besides R. From what you are saying, it seems I'll need to go
back to my Linux-like days and install R and R packages from sources,
and use a package manager to manage installing the needed libraries
and tools.

Anyway, thanks for the comments and suggestions.

When I get chance, I'll see if the same opm issues persist if I remove
all the homebrew stuff and retry with CRAN's mac binary directly and
then follow back up here and also with the respective package
maintainers.

All the best and "God P?ske" as they say in my parts (Happy Easter)

Gavin
On Sat, 19 Apr 2025 at 23:40, Simon Urbanek <simon.urbanek at r-project.org> wrote: