Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

On my version of Mac OS X ( 10.7.1 (Lion) and 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.

If installing the latest Xcode, will I get a more recent version of LLVM/Clang?

Are there any possible issues installing Clang manually ?

Once installed, will the new Clang be used automatically by all the IDEs I have (e.g., NetBeans )?

also note that Apple uses their own versioning for llvm/clang. So, Apple LLVM 3.0 / clang 3.0 are different from llvm.org's LLVM 3.0 :) The latter are more recent. – Anton Korobeynikov Dec 30, 2011 at 9:38

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)

I'm on Xcode 4.4.1 and I still see: Apple clang version 2.1 (tags/Apple/clang-163.7.1) (based on LLVM 3.0svn) Target: x86_64-apple-darwin11.4.0 Thread model: posix – James McKinney Sep 10, 2012 at 16:08 I'm on the same version of Xcode but clang --version reports: Apple clang version 4.0 (tags/Apple/clang-421.0.60) (based on LLVM 3.1svn) Target: x86_64-apple-darwin12.1.0 Thread model: posix. Perhaps you have an older version of Xcode still installed alongside 4.4.1? Also check the Downloads tab in Xcode's preferences to see if the Command Line Tools component has been installed. – Alistair McMillan Sep 16, 2012 at 13:33 @JamesMcKinney You may need to run xcode-select on the command line to point your system at the version of clang installed with the version of Xcode that you have installed. – leecbaker May 6, 2014 at 16:12 this no longer works as that tap is now empty. $ brew tap homebrew/versions returns "Warning: homebrew/versions was deprecated. This tap is now empty as all its formulae were migrated." Is there any way to do this now? – Brandon H. Gomes Dec 20, 2017 at 0:59

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.

Update: The current Xcode 4.3.3 for OS X 10.7 has a newer version of clang : Apple clang version 3.1 (tags/Apple/clang-318.0.61) (based on LLVM 3.1svn) . – Ned Deily Jul 6, 2012 at 16:39 Apple's version numbering does not match clang's. Apple clang 3.1 is built base on source prior to clang 3.1 went final. It's missing some C++11 features like initializer lists. They also bumped the version to 4.0 in 4.4DP but it's still clang 3.1 level feature-wise. – Stephen Chu Jul 7, 2012 at 18:25 That's FUD, stable releases of clang are fairly stable and other operating systems like FreeBSD track the latest version – jupp0r Jun 9, 2015 at 7:28 I'm not sure to what your FUD comment refers but what versions of clang are used by FreeBSD and other operating systems isn't relevant to the point I was making. For better or for worse, Apple supplies its own versions of clang and other tools as part of Xcode and the Command Line Tools and those are what Apple itself uses to build OS X and what they support for developers to use. Sure, usually you can use other versions or other compilers (e.g. gcc) and everything will be fine. But, when you do run into that weird problem or you need that special option, why make life more difficult? – Ned Deily Jun 9, 2015 at 16:20 Because you might want to use features included in an LLVM release that are not included in AppleClang. I did this yesterday for coroutines TS for example. – jupp0r Dec 20, 2017 at 1:09

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.

Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn) Target: x86_64-apple-darwin12.2.0 Thread model: posix $ clang++ --version Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn) Target: x86_64-apple-darwin12.2.0 Thread model: posix $ llvm-g++ --version i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ llvm-gcc --version i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

You can update Xcode for Lion too from the App Store or Apple Developer Account direct download, and install the command line tools, which will update Clang and LLVM to the above versions.

OS X Update version 10.9.2 (Mavericks) brings Xcode to version 5.1 (5B130a), and Clang to the latest stable (for OS X):

clang --version
Output:
Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix
On my Mac, llvm-gcc and llvm-g++ are symbolic link to this Clang:
lrwxr-xr-x  1 root  wheel     5B 25 Oct 16:48 /usr/bin/llvm-gcc -> clang
lrwxr-xr-x  1 root  wheel     7B 25 Oct 16:48 /usr/bin/llvm-g++ -> clang++
My latest R installation is configured to use llvm-gcc-4.2 which would cause error when building SHLIB. Creating symbolic links 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.
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.