Mac OS/X universal tarball with llvm-gcc 4.0 and all other LLVM tools This is most useful if you want a no-fuss drop-in replacement for Apple GCC. To install this, sudo to root, then untar in /. This installs tools in /usr/local/bin, which work on either ppc and intel macs. In addition, llvm-gcc supports the -arch option for Apple-style cross. Clangd can be installed. Download the LLVM installer from releases.llvm.org. Versions before 8 were part of the clang-tools. Xcode 12 builds Universal apps by default to support Mac with Apple Silicon, often without changing a single line of code. Designed for macOS Big Sur. Xcode 12 looks great on macOS Big Sur, with a navigator sidebar that goes to the top of the window and clear new toolbar buttons.
Question or issue on macOS:
On my version of Mac OSX (Lion 10.7.1, XCode 4.1), there is LLVM 3.0svn and Clang 2.1.
The current versions are LLVM 3.0 and Clang 3.0.
From the XCode web site, it seems that the latest version (4.2.1) still uses LLVM 2.0, and this seems to be a mistake.
Do you know if installing the latest XCode I will get a more recent version of LLVM/Clang?
Do you know of any possible issues installing Clang manually?
Once installed, will the new Clang be used automatically by all the IDEs I have (e.g. NetBeans)?
How to solve this problem?
Solution no. 1:
Software vendors are traditionally conservative about updating build tools and with good reason. If you want to use the latest publicly-supported versions of build tools supplied and modified by Apple, you should stick to those in the latest version of Xcode for the OS X release you are running. There are usually good reasons why Apple has not yet updated to the latest cutting-edge versions of open source components, like serious bugs. If you don’t need the Apple-supplied modifications and don’t mind living on the edge – i.e. no support from Apple and possibly (re-)discovering known problems – and are not planning to ship compiled files to other people’s systems, you could install your own versions in, say, /usr/local/bin or by using third-party package managers, like MacPorts http://www.macports.org/ports.php?by=name&substr=clang). You should definitely not try to replace the files at the paths installed by Xcode. Is it worth it? Only you can decide that.
Solution no. 2:
The web site is incorrect. Xcode 4.2.1 and 4.2 include LLVM 3.0 and clang 3.0:
clang –version
Apple clang version 3.0 (tags/Apple/clang-211.12) (based on LLVM 3.0svn)
clang++ –version
Apple clang version 3.0 (tags/Apple/clang-211.12) (based on LLVM 3.0svn)
llvm-g++ –version
i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)
llvm-gcc –version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)
Solution no. 3:
You can comfortably build your own LLVM using homebrew:
Download Clang Format For Windows
There are also versioned packages in case you need a specific version:
Solution no. 4:
I highly recommend against replacing the system compiler on macOS:
Many build processes you will see (e.g. Xcode) rely on Apple-specific extensions. For example, last I checked Apple have their own linker.
Also, Linuxes do not enforce binary compatibility — generally, people build software from source, or download specific binaries for each operating system version. As an end-user (as opposed to developer/professional user) operating system, macOS goes to great effort to maintain compatibility with binaries built on older macOS versions.
Replacing the compiler, or worse, system libraries, will break these compatibility guarantees. It may also break your system in subtle, non-obvious ways.
But feel free to install a second copy of clang in /usr/local or so and explore new features, but leave the system compiler alone.
Also note that Apple do not support submitting software to the app stores that aren’t built with Xcode and the compiler it includes. While you may go unnoticed if you do that, you may get rejected during app store review if your compiler fails to do anything that Apple’s compiler does.
Solution no. 5:
On Mountain Lion 10.8.2 with XCode 4.6, the versions are:
You can update XCode for Lion too from App Store or Apple Developer Account direct download, and install the command line tools, which will update clang & llvm to above versions.
Download Clang-format For Mac
Solution no. 6:
OS X Update version 10.9.2 brings XCode to version 5.1 (5B130a), and clang to the latest stable (for OS X):
On my Mac llvm-gcc and llvm-g++ are symlinks to this clang:
My latest R installation is configured to use llvm-gcc-4.2 which would cause error when building SHLIB. Creating symlinks for llvm-gcc-4.2 and llvm-g++-4.2 the same way, instead of replacing LLVM or CLANG, is enough to resolve the errors.
Hope this helps!
Development Tools and Libraries
CRAN R 4.0.0 builds and higher no longer use any custom compilers and thus this directory is no longer relevant. We now use Apple Xcode 10.1 and GNU Fortran 8.2 from https://github.com/fxcoudert/gfortran-for-macOS/releases.For more details on compiling R, please see alsohttps://mac.R-project.org/tools/Previous tools
The following is provided as support of older versions of R. If you use R 4.0.0 or higher, please disregard and read the top section.R 3.5.0-3.6.3 El Capitan binaries and higer were using more recent Clang compiler and GNU Fortran 6.1 to provide OpenMP parallelization support and C++17 standard features. If you want to compile R packages from sources, please download GNU Fortran binary from the official GNU Fortran Binaries page - in particular OS X 10.11 gfortran 6.1. Alternatively, we are providing a copy here as well as Clang binaries for OS X 10.11 and higher - see below for the download links.
Files:
| clang-8.0.0.pkg (OS X 10.11+, signed, 64-bit) MD5-hash: 664582b0722cb59802cb762b2ad7548b (ca. 482Mb) | Clang 8.0.0 for OS X 10.11 and higher, release build for x86_64, signed package, installs into /usr/local/clang8. To be used with El Capitan builds of R 3.7.0 and higher. It is an installer version of the official LLVM released binaries only modified to use the path above. |
| clang-7.0.0.pkg (OS X 10.11+, signed, 64-bit) MD5-hash: cef3fd2a5c165d00f9941f64ea4024f7 (ca. 463Mb) | Clang 7.0.0 for OS X 10.11 and higher, release build for x86_64, signed package, installs into /usr/local/clang7. To be used with El Capitan builds of R 3.6.x. It is an installer version of the official LLVM released binaries only modified to use the path above. |
| clang-6.0.0.pkg (OS X 10.11+, signed, 64-bit) MD5-hash: c29700c4e7b2914073ef7e741eb105bc (ca. 418Mb) | Clang 6.0.0 for OS X 10.11 and higher, static build for x86_64, signed package, installs into /usr/local/clang6. To be used with El Capitan builds of R 3.5.x. |
| gfortran-6.1.pkg (OS X 10.11+, signed, 64-bit) MD5-hash: 201026216e8b373d9cd2efc0cc474bb8 (ca. 73Mb) | GNU Fortran 6.1 for OS X 10.11 and higher - a copy from GFortranBinaries pages for x86_64, signed package, installs into /usr/local/gfortran (identical content, re-packaged to a flat Installer package and signed). To be used with El Capitan builds of R. |
| The following binaries are obsolete and only provided for historical reasons | |
| gfortran-4.2.3.pkg (OS X 10.5+, signed, 64-bit driver) MD5-hash: 8783f803038abe6487a362ad5b8995ea (ca. 27MB) gfortran-4.2.3.dmg (OS X 10.4, 32-bit driver) MD5-hash: 9551fc46f55537dd1db581154daf27ef (ca. 27MB) | Universal GNU Fortran 4.2.3 for Mac OS X 10.4 and higher. It is necessary in order to build R packages from sources that contain Fortran code. Unlike many other builds, this is a fully universal build of GNU Fortran that uses Apple's driver and supports all target architectures (i386, ppc, x86_64 and ppc64). As such it fully supports compilation into fat files like gfortran -arch i386 -arch ppc -arch x86_64 -arch ppc64 t.f -o ton both Intel Macs and PowerPC Macs (32- and 64-bit). Dependent libraries are fat as well, avoiding problems known from other Fortran builds (such as those from HPC). It installs in /usr/local and comes with an uninstall-script. |
| tcltk-8.5.5-x11.pkg (OS X 10.5+, signed) MD5-hash: e7c406d91762ffdc4539b23c5b5a3ab4 (ca. 9MB) tcltk-8.5.5-x11.dmg (OS X 10.4) MD5-hash: c32dda1b9f2c2776a02cec4e03befc76 (ca. 9MB) | Universal build of Tcl/Tk 8.5.5 for X11 (32-bit and 64-bit). This library is necessary in order to use the tcltk R package (for R 2.8.0 - 2.15.3 only!). It installs in /usr/local. Requires Mac OS X 10.4 (Tiger) or higher for 32-bit R and Mac OS X 10.5 (Leopard) or higher for 64-bit R. NOTE: R 3.0.0 and higher comes bundled with Tck/Tk 8.6.0 so you do not need this package |
For other (optional) 3rd party libraries for development see http://mac.R-project.org/libs/. The devpack has been superseded by those libraries. For R you may want to download and install libpng, libjpeg, readline, freetype, fontconfig, pixman and cairo.
Source code for all 3rd party libraries can be found at http://mac.R-project.org/src/
The dependency libraries used by the CRAN macOS build system are now managed by build recipes. Package authors wishing to add static dependendies can create a pull request to add a dependency.
Subdirectories:
| old | Previous versions of tools as supplied with legacy R versions. |
You may also want to read the R FAQ and R for Mac OS X FAQ. For discussion of Mac-related topics and reporting Mac-specific bugs, please use the R-SIG-Mac mailing list.
Information, tools and most recent daily builds of the R GUI, R-patched and R-devel can be found at http://mac.R-project.org/. Please visit that page especially during beta stages to help us test the Mac OS X binaries before final release! The page also contains links to experimental builds as such 64-bit R for OS X.
Link to corresponding sources: http://mac.R-project.org/src/
Last modified: 2020/04/24, by Simon Urbanek