PSA: setting the correct PATH for compilation on OSX

Hi all, I recently ran into a rather confusing (to me) problem with the PATH in my .zprofile and .bash_profile. It was suggested that I might post about it here.


In a failed attempt to get OpenMP working, I installed llvm with brew install llvm. This didn’t play nicely with the compiler flags that I was using for arm64 architecture, and so after fiddling around blindly for a while, I eventually reinstalled llvm and then uninstalled it with brew uninstall llvm.

The problem

After uninstalling, I was left in a state where the behavior of Stan, called from R (with or without Rstudio) depended on whether I opened R(studio) by double-clicking the icon in the /Applications folder or opening it via Terminal with open /Applications/ or open /Applications/ Instances opened by double clicking worked completely as expected. Instances opened from Terminal displayed the following behavior:

  • failure to compile any c++, erroring with error: can't exec '/opt/local/libexec/llvm-10/bin/clang++' (errno=NO such file or directory). This same error was also returned by Terminal when running, for example clang++ -v.
  • cmdstanr::check_cmdstan_toolchain() indicated that the toolchain was set up properly.
  • From R, dirname(Sys.which("clang++")) (which is used by cmdstanr::check_cmdstan_toolchain()) returned "/opt/local/bin"
  • Setting the PATH in my ~/.zprofile or ~/.bash_profile to the above path (i.e. export PATH="/opt/local/bin:$PATH"") didn’t change anything.

The solution

I needed to set the PATH to “/usr/bin” (i.e. export PATH="/usr/bin:$PATH"). This worked after an install of Xcode (not just Xcode command line tools), but I don’t have any reason to believe that the install of Xcode was necessary, except to help me troubleshoot (see below).

How I got there

After installing Xcode, the output of R’s dirname(Sys.which("clang++")) changed from "/opt/local/bin" to "/usr/bin", which was the path I needed.

What I think was going on

My env had PATH=/opt/homebrew/bin:/opt/homebrew/sbin:/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin
I don’t know why R (both the versions that worked after launching by double-click and the versions that didn’t work after launching with terminal) initially returned "/opt/local/bin" from dirname(Sys.which("clang++")), but in any case I think this wasn’t the correct path. Then, the Terminal-launched instances of R were looking on my PATH variable and going to /opt/homebrew/bin, which was still trying to point to my uninstalled llvm. Something like that anyway. Thanks to @ahartikainen who patiently helped me through parts of this.


Wow, sounds like a headache but glad you and @ahartikainen sorted it out.

So this is what messed everything up? Or did I misunderstand?

Well brew install llvm messed things up because it installed a version of C++ that didn’t support the compiler flags that I wanted (maybe there would have been other problems too, but the first error that I got was about my architecture flags or something like that–probably specific to M1). It’s possible that everything would still have worked fine if I’d just abandoned certain compiler flags, but I didn’t want to do that and everything else followed.

Edit: that could be wrong. In my misadventures with OpenMP, I first tried installing llvm with macports, and then when I couldn’t get OpenMP working that way I tried with homebrew. So it’s possible that my macports installation of llvm was responsible. But I don’t think so, because the problem on the PATH variable seems to have involved /opt/homebrew.

Edit2: This was originally an attempt to enable multi-threading with data.table, which seems like a potentially common enough use case for mac users who are also using Stan. If anybody can get a Mac to the point where it can use both data.table with OpenMP and cmdstanr with

CXX=arch -arch arm64e clang++
CXXFLAGS+= -mcpu=apple-a14

I’d love to hear about it!

@jscolar Courageous! That Apple disabled openMP with recent Xcode versions is very annoying.

But I wonder if the following might have been helpful …

1 Like

Maybe so, but I’m not courageous enough to try it just yet! :P

Perhaps there were discrepancies between .bashrc and .bash_profile that resulted in this error (Stack Overflow). Sounds like that could come into effect if you open the application through an interactive shell or by double-clicking.