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.



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:


Build Failures

New Build failures from clang7

Please see /Clang7Regressions.

New Build failures from clang6

Please see /Clang6Regressions.

Notes on error classification

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:

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:

Older Build failures with fixes




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.

(!) 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.

Build failures without fixes yet



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

Build failure false positives

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


Runtime failures

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


If you're interested in helping

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


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

Obsolete versions of llvm/clang


CategoryPorts CategoryStale

PortsAndClang (last edited 2021-04-24T06:08:11+0000 by KubilayKocak)