Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using gcc on macOS as the default compiler? #4016

Closed
pat-s opened this issue Oct 31, 2019 · 5 comments
Closed

Using gcc on macOS as the default compiler? #4016

pat-s opened this issue Oct 31, 2019 · 5 comments

Comments

@pat-s
Copy link

pat-s commented Oct 31, 2019

After reading and trying the compiler instructions for macOS, I was wondering if gcc from homebrew would be a better alternative than llvm.

As stated in the wiki, an openmp enabled compilers causes issues with other packages. It is quite cumbersome to comment out the llvm compiler all the time if one wants to compile other packages.

Currently I am using the following setup with gcc installed via brew install gcc. No issues so far for any packages.

CXX_STD = CXX14

CC=ccache /usr/local/bin/gcc-9
CC11=ccache /usr/local/bin/gcc-9
CC14=ccache /usr/local/bin/gcc-9
CXX=ccache /usr/local/bin/g++-9
CXX11=ccache /usr/local/bin/g++-9
CXX14=ccache /usr/local/bin/g++-9
## -O3 should be faster than -O2 (default) level optimisation ..
CFLAGS=-g -O3 -Wall -pedantic -std=gnu99 -mtune=native -pipe
CXXFLAGS=-g -O3 -Wall -pedantic -std=c++11 -mtune=native -pipe

In addition, I am using ccache as you can see. Combined with the ~/.ccache/ccache.conf settings below, I have a robust C compiler setup which supports caching.

max_size = 5.0G
# important for R CMD INSTALL *.tar.gz as tarballs are expanded freshly -> fresh ctime
sloppiness = include_file_ctime
# also important as the (temp.) directory name will differ
hash_dir = false

(The ccache part is taken from this post by Dirk.)

@renkun-ken
Copy link
Member

I'm using the approach suggested at https://github.com/rmacoslib/r-macos-rtools. I use the clang7 provided at https://cloud.r-project.org/bin/macosx/tools and only have to specify the following in ~/.R/Makevars:

CC=/usr/local/clang7/bin/clang
CXX=/usr/local/clang7/bin/clang++
CXX1X=/usr/local/clang7/bin/clang++
CXX11=/usr/local/clang7/bin/clang++
CXX14=/usr/local/clang7/bin/clang++
CXX17=/usr/local/clang7/bin/clang++
LDFLAGS=-L/usr/local/clang7/lib

And everything works smoothly and consistently.

I'm not sure why the macOS instructions look so complicated, which will easily make beginner users who use macOS have a hard time even installing latest data.table from source.

@pat-s
Copy link
Author

pat-s commented Jan 2, 2020

For me, the gcc approach is the fastest and most stable one so far.
I am not sure though what other caveats this might introduce on macOS. 🤔

@jangorecki Who is in charge for the C-related part in {data.table} or might have more in-depth knowledge about what is going on behind the scenes?

gcc is the compiler used on all major Linux distros, is there anything preventing it from setting it as the default on macOS?

@jangorecki
Copy link
Member

There is no single person in charge of C part of DT. Matt and Arun wrote most of C stuff. AFAIR @arunsrinivasan is on macOS so his views on this issue could be very helpful.

@jangorecki
Copy link
Member

jangorecki commented Nov 23, 2020

I prefer to use gcc myself as well, but it happens that clang is the default one on MacOS. Trying to change default compiler globally for Mac users would causes more issues than it resolves. So I don't think changing default is the way to go.
Now that #4735 is merged (and already published to CRAN as 1.13.2), users should be able to more easily customize their build of data.table. Therefore it should address your use case. If it doesn't please let us know.

@mattdowle
Copy link
Member

Hi @pat-s. Thanks for your input here. I would just add that if the MacOS instructions on our Installation page can be simplified, that would be very welcome. Please go ahead and make the changes directly yourself to the wiki. There are no permissions needed to change the wiki, which is the very reason we made it a wiki.

@jangorecki jangorecki removed this from the 1.13.7 milestone Dec 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants