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
Contents
Quickstart
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
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:
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:
bad C++ code (somewhat common)
compiler error (somewhat common)
configure (somewhat less common)
linker error (quite common)
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.
Older Build failures with fixes
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. |
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
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 |
Build failure false positives
Don't worry about these. They are not your problem.
(TBA)
Runtime failures
Just because a port compiles, does not necessarily imply that it functions correctly:
(TBA)
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.
- Reporting clang/llvm bugs upstream
- Debugging miscompilations
- Submitting ports PR with fixes
PRs
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
Please see ObsoleteLLVMVersions.