Clang

Clang is Article description::a "LLVM native" C/C++/Objective-C compiler using LLVM as a backend and optimizer. It aims to be GCC compatible yet stricter, offers fast compile times with low memory usage, and has useful error and warning messages for easier compile troubleshooting.

Prerequisites
One of the goals of the Clang project is to be compatible with GCC, in dialect and on the command-line (see ). Occasionally some packages will fail to build correctly with it and some may build successfully but segfault when executed. Some packages also have GCC specific code and will also fail during compiling. In these events, GCC will need to be used as a fallback.

USE flags
Some packages are aware of the USE flag.

GCC fallback environments
Create a configuration file with a set of environment variables using Portage's built in directory. This will override any defaults for any packages that fail to compile with clang. The name used below is just an example, so feel free to choose whatever name is desired for the fallback environment. Be sure to substitute chosen name with the examples used in this article.

The above is the most basic environmental variable needed. You can change it to suit your needs, such as enabling/disabling link-time optimizations, alternative AR, NM, RANLIB, and so on. Here are two examples below:

Basically, copy over your current working GCC config from your make.conf in the event we need to use it as a fallback. If you choose to use LLVM's implementation of AR, NM, and RANLIB as detailed later in the article, be sure to set them back to the GNU versions for your GCC fallback environments as shown in the above example. If you choose not to, you can ignore the AR, NM, and RANLIB variables. If you want to use link-time optimization it's a good idea to have two separate environments like the above examples.

In the event you have to use the GCC fallback environment(s) set the appropriate flags in the file.

Clang environments
Now that we've set up a safe fallback we can proceed to enable the usage of Clang in Gentoo. There are two ways to do this: System wide using or via environmental variables like the one(s) we created for the GCC fallback.

We'll use the same process as we did earlier in the article for setting up GCC fallbacks.

You can now use Clang on a per package basis by invoking the compiler-clang environmental variable you created.

The setup of a clang + LTO environment is described later in the article.

Global configuration via make.conf
When attempting to use Clang system wide the system absolutely must have a GCC fallback! This cannot be stressed enough as the system will not be able to compile everything using Clang at the moment, such as the GCC compiler. Gentoo maintains a bug tracker for packages that fail to build with Clang. Configuring Gentoo to use Clang system wide is simple. Change the CC and CXX variables in to reference the Clang equivalents. No further configuration is necessary.

Packages that must use GCC for compiling can be handled with one of the fallback environments created earlier.

Bootstrapping the Clang toolchain
Mixing clang and its toolchain / libraries with the gcc toolchain / libraries (especially the linker) will often lead to issues like linker errors during emerge. To prevent this, the clang toolchain is built first with gcc and then with itself to get a self-providing compiler.

Prepare the environment for the Clang toolchain (see above), e.g.

This example replaces not only the compiler but also the GNU linker ld.bfd with the llvm linker lld. It is a drop-in replacement, but significantly faster than the bfd linker.

Set USE flags  for clang. Then emerge clang llvm compiler-rt llvm-libunwind lld with the default gcc environment:

You can also add the  USE flag to use llvms C++ STL with clang, however this is HEAVILY discouraged as libstdc++ and libc++ are not ABI compatible. A program built against libstdc++ will likely break when using a library built against libc++, and vice versa.

Note that sys-libs/llvm-libunwind deals with linking issues that sys-libs/libunwind has, so it is preferred to use and replaces the non-llvm libunwind package if installed (it builds with -lgcc_s to resolve issues with __register_frame / __deregister_frame undefined symbols).

Enable the clang environment for these packages now:

Repeat the emerge step with the new environment. The toolchain will now be rebuild with itself instead of gcc.

You are now free to use clang with other packages.

Link-time optimizations with Clang
The link-time optimization feature defers optimizing the resulting executables to linking phase. This can result in better optimization of packages but isn't standard behavior in Gentoo yet. Clang uses lld for LTO.

Note: Clang can also do LTO via the gold linker, however this is discouraged by llvm since gold is effectively dead upstream. To use gold with clang + LTO, you must first emerge llvm with the  USE flag, and then set   in the following examples.

Environment
Clang supports two types of link time optimization:


 * Full LTO, which is the traditional approach also used by gcc where the whole link unit is analyzed at once. Using it is no longer recommended.
 * ThinLTO, where the link unit is scanned and split up into multiple parts. With ThinLTO, the final compilation units only contain the code that are relevant to the current scope, thus speeding up compilation, lowering footprint and allowing for more parallelism at (mostly) no cost. ThinLTO is the recommended LTO mode when using Clang.

If you need to use full LTO for some reason, replace  with   in the following examples. There should be no compatibility differences between Full LTO and ThinLTO. Additionally, if you did not build Clang with the  useflag, you will have to add   to the following LDFLAGS.

As an alternative, LLVM provides their own ar, nm, and ranlib. You're free to use them and may or may not get more mileage over using the standard ar, nm, and ranlib since they're intended to handle LLVM bitcode which Clang produces when using the  flag.

Now you can set overrides using Clang with LTO enabled.

Global configuration
Similar to what we covered earlier in the article, we can do a system wide Clang with LTO enabled setup by changing our file.

Again, it's up to you if you want to set the AR, NM, and RANLIB to the LLVM implementations. Since earlier in the article we set up compiler environments using Clang without LTO, GCC without LTO, and GCC with LTO, we can pick and choose which is best on a per package basis. Since the goal is to compile packages system wide with Clang using LTO and not every package will successfully compile using it, we'll have to fall back to Clang with LTO disabled or GCC. Your may look like this:

distcc
In order to use clang on a distcc client, additional symlinks have to be created in /usr/lib*/distcc/bin:

ccache
Automatic with `>=ccache-3.9-r3` when Clang is emerged.

Troubleshooting
The main place for looking up known failures with clang is. If you hit one not reported on our Bugzilla already, please open a new bug report and make it block 408963.

Compile errors when using Clang with -flto
If the packages you're installing are failing, check your logs. Often times packages with errors like the following will need to disable LTO by invoking the compiler-clang environment.

You will also most likely see this error in every LTO failure case.

Simply add the failing package to your. In this case it's, so we'll apply the proper override.

Sometimes a package will fail to compile even when disabling LTO because it requires another package which was compiled using -flto and works incorrectly. You may see an error like this:

In this case libatomic_ops is causing boehm-gc to fail compiling. Recompile the program causing the failure using your non-LTO environment and then recompile the new program. In this case, boehm-gc fails when using LTO, so we'll add both of them to our file to build them without LTO.

Use of GNU extensions without proper -std=
Some packages tend to use GNU extensions in their code without specifying  appropriately. GCC allows that usage, yet Clang disables some of more specific GNU extensions by default.

If a particular package relies on such extensions being available, you will need to append the correct -std= flag to it:


 * for C89/C90 with GNU extensions,
 * for C99 with GNU extensions,
 * for C++:1998 with GNU extensions.

A common symptom of this problem are multiple definitions of inline functions like this:

This is because Clang uses C99 inline rules by default which do not work with gnu89 code. To work around it, you most likely have to pass  or set one of your environmental overrides to use GCC to compile the failing package if passing the right   flag doesn't work.

Since both current (2020) GCC and Clang default to  with C99 inline rules, chances are the problems have already been spotted by a GCC user.

Differences from GCC
Clang's optimizer is different from GCC's. As a result, the command-line semantics are different.
 * The  flags will work, but mean slightly different things.
 * Clang also vectorizes on  and , albeit more conservatively in terms of code size than.
 * Instead of being the same as, Clang's   is an alias of.
 * The compatibilty of  flags are limited as they can be simply meaningless to Clang.
 * The  and related flags are supposed to work identically, but Clang may not know about certain options. There are also Clang-only options not known by GCC.
 * The PGO in clang is a bit different as it requires post-processing the sample with.

The differences in language are documented by the project itself.

External resources

 * Playing with LLVM, gold linker and CLANG Gentoo Forums post