Ports and Clang

This page is for ports status with the clang compiler. Below you will find some common problems and solutions to some of these problems. Also a list of ports that are known not to work and need to be investigated, like KDE for example.

This is part of the ClangBSD project.

Contents

In all supported FreeBSD releases, Clang is the default compiler on all architectures except mips*, powerpc*, and sparc64. It is installed as cc, c++ and cpp. To test building ports with clang on other archs, add the following lines to /etc/make.conf:

CC=clang
CXX=clang++
CPP=clang-cpp

Please see Clang7Regressions.

Please see Clang6Regressions.

There is a script called processonelog on the build cluster that attempts to classify types of build errors. It is just a sequence of grep invocations that we keep updated with the results of various build failures over the years. You should not assume that its analysis is conclusive.

The errortypes created expressly for clang -exp runs:

  • assumes_gcc (for code that fails to configure with clang because of hardwired assumptions about gcc)
  • clang (for code that fails to compile with clang)
  • clang-bug (for bugs in the compiler itself, or code or invocation parameters it does not yet support)

Note the that following regressions might not be reported as clang, and instead as existing errors:

We know not all cases of clang will be caught by the script; the script needs to be optimized for performance reasons, and thus we cannot include all possible error cases.

Other notes:

  • You will see some errorlogs with reason cluster. Often for package builds this is a transient error, as the explanation claims. However, in some cases what is happening is that the configure step is spitting out clang errors having to do with unsupported options, and this makes the classifier script break. The configure step of these ports needs to be fixed.
Failure Why Solution
undefined or duplicate symbols while linking clang defaults to gnu99, while gcc defaults to gnu89. This causes problems with the inline and restrict keywords (and possibly others). inline does different things in gnu89/gnu99 add “USE_CSTD=gnu89” to the port Makefile
Not respecting ${CC} and/or ${CXX} Some ports have gcc/g++ hardcoded in their Makefiles. CC ?= gcc, or reinplace line.
/usr/bin/nm: .foo.o: File format not recognized clang produces llvm bitcode (used for LTO) when compiled with -O4. Use -O3 or lower.
error: expected ';' at end of declaration, nested function definition clang does not accept nested function definitions Move the nested function to a static function at global scope.

:idea: even if you add the gnu89 stanza to the port Makefile, you still have to re-test your build with gcc because the build may break there. In that case you may have to make the gnu89 stanza conditional on compiler.

Failure Solution
Assertion failed: (something) If you know what you're doing, reduce a testcase and report clang/llvm bug upstream. Otherwise, just explain us how to reproduce it and we'll do it for you.
UNREACHABLE executed at something
Clang crashes

Don't worry about these. They are not your problem.

(TBA)

Just because a port compiles, does not necessarily imply that it functions correctly:

(TBA)

If you want to help with something mentioned (or not) below, join us on IRC and feel free to talk to us about it.

  • Reporting clang/llvm bugs upstream
  • Debugging miscompilations
  • Submitting ports PR with fixes

You may be able to save yourself some time by looking at the current ports/ PRs mentioning clang. Some already have patches.

  • portsandclang.txt
  • Last modified: 2026/10/12 10:55
  • (external edit)