Installing rpy2 with the latest R 3.4.0 doesn't work on macOS. Apparently, R 3.4.0 was built using the '-fopenmp' flag with Clang 4.0.0, which is not supplied by Apple. Therefore, pip install rpy2 gives the following error:

An alternative might be to work out precompiled binaries for OS X but since I currently do not have access to a dev environment with OS X for rpy2, and since this would likely open up additional complexity because of R versions, this would have to be contributed by someone.

@pkulkarni2110 as a workaround, you can continue to use R 3.3.3, which is the last version that works with rpy2. @Laurent Gautier I have a Mac, but setting up the tools that were used to build R 3.4.0 could be a PITA. Unless I could just use the versions in Homebrew - I saw that they have LLVM version 4.0.0, but gcc is at 7.1.0 (and gcc@6 is 6.3.0 and not 6.1.0), so not sure it will be that easy. IMO it was quite an unfortunate decision from the R devs not to use Apple provided tools.

@Laurent Gautier either way this situation is not ideal, because it might entail having two pip packages for macOS depending on which R version you want to connect to. I don't think that this is even possible. Unless of course rpy2 built with the newer compiler versions also works with older R versions built with Apple-provided stuff.

I installed R ver 3.3. I installed XQuartz as it was mentioned in the R webpage to install in macOs. I cannot certainly say it was helped to resolve the issue in anyway. Yes it is not ideal situation but it did work for temporarily.

Installing XQuartz is not necessary. I agree that this is just a temporary workaround - all future versions of R will be built with the newer tools, so eventually rpy2 will need to support it. MacOS High Sierra will likely ship with these updated build tools, so when rpy2 is built for this platform everything should hopefully work with R 3.4.0 and higher. Still, the question remains how rpy2 will handle older macOS versions. I guess we'd have to try if building with the newer tools produces a package that works both with R 3.4.0 as well as older versions such as R 3.3.3. I can try to build it and see if it works when I have time.

@Clemens Brunner : I might be missing something here. How is this a support issue with rpy2 rather than an inconvenience of the R binaries on OS X ? rpy2 is getting its compilation flags (-fopenmp, presumably among other flags, here) from the installed R binary.

Because rpy2 doesn't work with R 3.4.0 or later, since setup.py requires a clang version that supports the -fopenmp flag. Since rpy2 gets the compiler flags from the R binary, is it possible to disable the -fopenmp flag if it is found? This would probably solve the issue.

It might install, and may be even run, but that not something I'd like to hardcode in setup.py (which would mean support it). We can leave your workaround, someone may want to contribute "wheel" binaries for OS X, but otherwise building from source will require the toolchain the R binary itself was built with.

OK, but so far the source wheels worked and you only need a binary wheel for macOS using R >= 3.4.0 and all sorts of Python versions. The minimum should be Python 3.6 here, so this would be only one wheel if patch version levels are not important (i.e. Python 3.6 works like 3.6.1, similarly for R 3.4.0 and 3.4.1 etc). Let me know if you need anything from me to create this binary wheel.

To piggyback of this issue, I have also been experiencing this same bug, though I am using R version 3.4 and Python version 2.7. would there be any way to get rpy2 to function with Python 2.7? I have been experiencing a great number of difficulties in trying to install rpy2, despite having tried pip, easy_install, and downloading the source tar. Despite my R being up to date and located in the PATH environmental variable, I have consistently received the same error:

I have tried numerous approaches to solving this, including downloading XCode for OSX, as well as importing architecture flags, such as:

envARCHFLAGS="-arch i386 -arch x86_64"pipinstallrpy2

I have also tried to installing the latest GCC compilers, but that made no change on the error yielded during rp2's installation process. Then I tried implementing commands suggested by Clemens Brunner above, and found that they worked perfectly, but only for Python 3.4. Is there any other approach you would recommend in order for rpy2 to function with Python 2.7?

I have followed @ Clemens Brunner and run the following three command. I installed llvm, set the environment in .bash_profile, and source it to activate the change. I installed rpy2 in python3. But I still got the same error.

Somehow the build process still uses gcc instead of clang. I don't know why this worked for me out of the box, but you could either symlink gcc to clang (and g++ to clang++), or explicitly tell pip to use clang (this is actually where I'll stop, because I have no experience with distutils, but you could try to go from here or here). Alternatively, you could try the simpler option I mentioned above (add the two lines to setup.py and install via python3 setup.py install). Lastly, if you install the package directly without pip, you could also try python3 setup.py install --compiler=clang.

BTW, although Apple has updated clang in High Sierra, they have disabled the fopenmp option. So unfortunately this means that installing rpy2 on a Mac via pip still doesn't work out of the box (if the latest R version is installed).

Thanks Clemens, I was also not sure why I needed to upgrade JDK, but it came up when I used conda. There may be some interaction in my set up. Also conda install rpy2 does not always work on Mac environments (I have tried several), but seems to always work on all my Ubuntu setups. Not sure why, but I am relieved, and happy to have my Python and R systems talking happily to each other again on my main Macbook Pro. Appreciate all your help with this on this forum.

I was having the same issue and followed these instructions but installation (pip install rpy2) failed with:

ld: in '/usr/local/opt/llvm/lib/libunwind.dylib', file was built for x86_64 which is not the architecture being linked (i386): /usr/local/opt/llvm/lib/libunwind.dylib for architecture i386
clang-5.0: error: linker command failed with exit code 1(use -v to see invocation)
error: command'/usr/local/opt/llvm/bin/clang' failed with exit status 1

Hi! I have faced the problem with openmp on Sierra and have solved it.
1. Setting the environment variable CC in .bash_profile or aliasing gcc to gcc-7 (installed by brew) doesn't work
2. The solution proposed by @jzweig works perfectly, namely:

Interesting to see that almost everyone needs to do something different in order to install rpy2. Bottom line is that rpy2 currently cannot be installed on Macs out of the box via pip. A binary wheel would solve all these issues. I'm still willing to contribute a Mac binary, @Laurent Gautier let me know when you are ready.

The fact that everyone appear to require something different is making me think that one binary might not work for all.

What about writing rules for all cases reported so far into a Python script as a first step ? Patterns will likely emerge in the process, and with this a better understanding of how to address the issue in the most general way possible.

@Clemens Brunner : my experience with Windows builds for rpy2 is that the build script should have about everything needed to:
- build without manual intervention / setup by default
- test requirements and report missing ones in an intelligible way to a user trying to install

Without this the "should work" turns into a stream of posts on StackOverflow, issue reports, or even personal emails that take away too valuable time as there is suddenly an influx of users without the knowledge to setup a dev environment, and a wider gap to fill to compile in their own environment in order to troubleshoot (check the number of issues in the tracker or on OS about compiling rpy2 on Windows). In that case, leaving it to "no official support" is the most optimal alternative.

@freakwill do you mean compile to LLVM's intermediate representation or use clang to compile R. The later is reported to be the way the official R binaries are built (with gfortran need - link to R's own doc found earlier in this thread: https://cran.r-project.org/bin/macosx/tools/).

The resolution to the problem raised by this thread would be:

install gfortran as the R doc ask it

use gcc instead of clang

With respect to rpy2, and a user-friendly resolution, this should translate into setup code that help handle to the switch and if possible checks are informative reports about what is missing an options at the top level. I do not have OS X to do rpy2 development, and was hoping that the OS X community would step up (I appreciate the offer to build binaries, but this is not a viable solution without having code to let anyone build the binaries easily first).

Do you need to use Python 2? If possible, please switch to Python 3, then you should be able to make it work. Note that Homebrew recently made Python 3 the default Python. That is, if you brew install python you get Python 3. You might need to brew uninstall python followed by brew install python.

@Laurent Gautier the only user-friendly way here is to distribute binaries on PyPI. You can't expect Mac users to install tools like gfortran or gcc. Therefore, only devs who build the binaries should be required to do that. If I understand you correctly, you want to integrate this stuff into setup.py, right? I'm not that familiar with the PyPI packaging process, so if we added code to setup.py could we create Mac binaries that just work (i.e. don't require compilation at all)?

Well, the error message is clear: rpy2 no longer supports Python 2! You can try to install an older version of rpy2 with pip, e.g. pip install rpy2==2.8.6. I'm not sure which version still works with Python 2, so you might need to try different versions.

Yes. I just did not know which and how to try older versions.
It seems now that I have another problem:
$ pip install 'rpy2<2.9.0' --user
-bash: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/pip: No such file or directory

and the same with your suggestion:
$ pip install rpy2==2.8.6
-bash: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/pip: No such file or directory

The only user-friendly way here is to distribute binaries on PyPI. You can't expect Mac users to install tools like gfortran or gcc. Therefore, only devs who build the binaries should be required to do that. If I understand you correctly, you want to integrate this stuff into setup.py, right? I'm not that familiar with the PyPI packaging process, so if we added code to setup.py could we create Mac binaries that just work (i.e. don't require compilation at all)?

What I mean is that building on Mac should only be a matter of running the install script, eventually setting an environment variable like CC to specify the C compiler, and inform the user if a dependency is missing (up to the user to install it).

Now this is largely influenced by the experience maintaining Windows binary builds in the beginning of the project. Building rpy2 was a complex process with manual steps and configuration tweaks, and when binaries stopped being officially maintained this created confusions, email traffic, and issues opened on the tracker, among users that are not familiar with compiling software, or who are familiar with it but are also used to simpler compiling processes.

Having a simple build process, and informative messages about missing dependencies to the extent possible, will ensure that I can start having contributed binaries (as I currently do not have an OS X for rpy2 development) knowing that:

should the contributor of binaries move on it will be relatively easy to find someone else to help

should more frequent binaries (e.g., from the dev branch) or binaries including patches not yet in the main repos be needed by users it will not be excessively difficult for the user to either find someone to help or figure out how to compile

Yes, the steps mentioned in the SO answer work for me. The question is whether linking to libopenmp from Homebrew could be a problem for systems that don't have Homebrew. However, I guess most things don't use OpenMP in R, so almost everything should just work.

@Clemens Brunner : Got it. This is not a good solution then (if we are requiring users to install homebrew to use the binaries, we might has well require them to install homebrew and install from source).

I use the official R package. Actually, it's a framework build, which means that all libraries are contained in /Library/Frameworks/R.framework/Resources/lib. Among others, libomp.dylib is located inside that folder. I guess this lib path should be specified when rpy2 is built (I always thought that it asks R where all required libs are located, but I might be wrong). It might be possible that what I suggested at the beginning might work, because I'm not using libomp from Homebrew at all. I'll check.

a. rpy2 will be used with official R binary or any other compatible framework build, and in that case a pre-compiled rpy2 can be made available as a wheel. In that case we need to work out how to link to matching openmp at run time (may be at build time is required as well ?). I am not very familiar with framework builds in general, so I'll need your help to both have:

python setup.py install that is able to build against the official R binary relatively easily (code to detect and report clearly to the user what is missing will be needed once we have what we believe to be one of the simplest ways to build rpy2 against the official R binary )

Eventual additional dynamic setup at run time when importing rpy2.rinterface (or calling rpy2.rinterface._rinterface.initr())

b. rpy2 will be used with an other R binary, and in that case the user will be expected to compiled rpy2 from source. The current setup.py is already allowing it.

Yes, I think your understanding is correct. In the (unlikely?) event that mixing different versions of the header and the lib, we could even try to install the same libomp version with Homebrew that is shipped with the R binary. For now, I have successfully managed to build a binary wheel!

Good. If you make the wheel available for rpy2-2.9.3 available to me (attachment here, if possible, otherwise link on Dropbox / Google Drive / similar) I can push it to pypi and we can see how it appears to be working for all. I can monitor the number downloads for the wheel to check whether OS X users try to install it, and we(*) will follow the issues reported or messages of support.

(*: you are implicitly signing up to be receiving all praises, and share the issues I am unable to solve as I currently do not have access to an OS X I can use for rpy2 development)

I compiled rpy2 on os x using homebrew llvm, compiles fine. But in runtime, I get this error related to openmp:

OMP: Error #15: Initializing libomp.dylib, but found libomp.dylib already initialized.
OMP: Hint This means that multiple copies of the OpenMP runtime have been linked into the program. That is dangerous, since it can degrade performance or cause incorrect results. The best thing to do is to ensure that only a single OpenMP runtime is linked into the process, e.g. by avoiding static linking of the OpenMP runtime in any library. As an unsafe, unsupported, undocumented workaround you can set the environment variable KMP_DUPLICATE_LIB_OK=TRUE to allow the program to continue to execute, but that may cause crashes or silently produce incorrect results. For more information, please see http://openmp.llvm.org/

As the wheel builds are getting available, and popular, we will see new categories of issue reports coming from OS X users:

no build for their version of OS X

no build for their version of Python (Python 3.7 is around the corner)

no build version for their version of R (for that one, I guess we should have the information embedded in the wheel's description - I have not looked at what are the options to achieve this)

Also, I am getting ready to release rpy2-2.9.4 and ideally I'd coordinate the release of the source package on pypi after the wheels for OS X are tested (and I have a copy to upload them at the same as the source).

Isn't it feasible to run python -m rpy2.tests on different mac OS versions with different python3 combinations using CI on bitbucket? Or does it exist already? I'm not so familiar with rpy2 development.

@Clemens Brunner I have added the tag RELEASE_2_9_4 in branch version_2.9.x, and create issue #470 to track the relase of rpy2-2.9.4. Let me know if it is working.

Note that R-3.5 will see a segfault at the end of the unit tests (see issues #465 and #469). This is caused by changes in R's own object handling and fixing this might take me a bit of effort. I'd like to get rpy2-2.9.4 soon, so I can focus on rpy2-3.0.0 (as fixes for the issues just mentioned might require API-breaking changes in rpy2). Thanks.

Hi builders of rpy2 for OS X,
if you have have continuous building from dev (branch default), this is likely going to be a rocky road for few weeks: rpy2 is moving to a dual ABI / API interface to R. The API interface will be the fastest interface but will require compiling / a binary egg, but the ABI interface will be there when this is not available.

That work is currently in the branch cffi, but I intend to merge to default relatively soon.

And you are using Python 3.7 I assume? Why does your R framework not come with libomp.dylib? Can you check which files are in this location (/Library/Frameworks/R.framework/Versions/3.5/Resources/lib/)?

How did you install R then? Did you use the official installer package from https://www.r-project.org/? If not, you should do that, because rpy2 only supports this and not other variants such as e.g. Anaconda (but there should be a conda-installable package of rpy2).

(...)
Did you use the official installer package from https://www.r-project.org/? If not, you should do that, because rpy2 only supports this
(...)

Just to clarify: thanks to @Clemens Brunner we have binaries wheels easy to install for OS X users, and the comment about support only concerns these binaries.

rpy2 should otherwise work with pretty much any R installed where it was compiled with --enable-R-shlib.

On Linux whenever there is an issue and Anaconda is mentioned I do tend to redirect the reporter to Anaconda support, but there has been less issues reported over time (may be because rpy2 packaged for Anaconda is kept up to do date, so rpy2 users do not need to fetch it from Pypi.)