[llvm-dev] conflicting builtins in clang with musl (stddef.h)

David Demelier via llvm-dev llvm-dev at lists.llvm.org
Sat Aug 3 06:50:40 PDT 2019

Hello there,

I'm building a Linux distribution based on musl and LLVM as default
toolchain (including lld/libc++/libc++abi/libunwind rather than GNU).
For most of the time this works pretty well.

However I'm having troubles with few packages, webkit for instance
fails because of max_align_t being redeclared in musl's stddef.h

I see that stddef.h is provided by both musl and in the private clang
include directories.


Usually, compiling a sample program works:

$ cat test.cpp
#include <stddef.h>
#include <limits>
#include <type_traits>

int main() {

$ clang++ -std=c++17 -v test.cpp
Vanilla Linux clang version 8.0.0 (tags/RELEASE_800/final) (based on
LLVM 8.0.0)
Target: x86_64-unknown-linux-musl
Thread model: posix
InstalledDir: /bin
 "/bin/clang-8" -cc1 -triple x86_64-unknown-linux-musl -emit-obj
-mrelax-all -disable-free -disable-llvm-verifier -discard-value-names
-main-file-name test.cpp -mrelocation-model pic -pic-level 2 -pic-is-
pie -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-
64 -dwarf-column-info -debugger-tuning=gdb -v -resource-dir
/lib/clang/8.0.0 -internal-isystem /bin/../include/c++/v1 -internal-
isystem /usr/local/include -internal-isystem /lib/clang/8.0.0/include
-internal-externc-isystem /include -internal-externc-isystem
/usr/include -std=c++17 -fdeprecated-macro -fdebug-compilation-dir /tmp
-ferror-limit 19 -fmessage-length 274 -fobjc-runtime=gcc -fcxx-
exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics
-o /tmp/test-0249b1.o -x c++ test.cpp -faddrsig
clang -cc1 version 8.0.0 based upon LLVM 8.0.0 default target x86_64-
ignoring nonexistent directory "/usr/local/include"
ignoring duplicate directory "/include"
#include "..." search starts here:
#include <...> search starts here:
End of search list.
 "/bin/ld.lld" -pie --eh-frame-hdr -m elf_x86_64 -dynamic-linker
/lib/ld-musl-x86_64.so.1 -o a.out /bin/../lib/Scrt1.o
/bin/../lib/crti.o /lib/clang/8.0.0/lib/linux/crtbeginS.o -L/bin/../lib
-L/lib -L/usr/lib /tmp/test-0249b1.o -lc++ -lm
/lib/clang/8.0.0/lib/linux/libclang_rt.builtins-x86_64.a -lc
/lib/clang/8.0.0/lib/linux/crtendS.o /bin/../lib/crtn.o

However, webkit's CMake for some reasons adds -isystem /include which
breaks the build with the error I mentioned above. I can reproduce it
with this example of code too:

$ clang++ -isystem /include -std=c++17 test.cpp      
In file included from test.cpp:2:
In file included from /bin/../include/c++/v1/limits:106:
In file included from /bin/../include/c++/v1/type_traits:406:
In file included from /bin/../include/c++/v1/cstddef:45:
In file included from /lib/clang/8.0.0/include/stddef.h:118:
/lib/clang/8.0.0/include/__stddef_max_align_t.h:40:3: error: typedef
redefinition with different types ('struct max_align_t' vs 'struct
} max_align_t;
/include/bits/alltypes.h:49:54: note: previous definition is here
typedef struct { long long __ll; long double __ld; } max_align_t;
1 error generated.

I've asked to the musl's maintainer and said that clang should not
provide std* files that are already present in musl. He also said that
the include order should be inversed to use '/include' first. I've
checked FreeBSD which also use clang and they effectively removed
stddef.h and all headers that are already provided by their own libc.

So I've tried to remove them temporarily but now, it's the opposite.
webkit fails to find stddef.h even though it's provided by musl in

# clang++ -std=c++17 -isystem /include test.cpp
In file included from test.cpp:2:
In file included from /bin/../include/c++/v1/limits:106:
In file included from /bin/../include/c++/v1/type_traits:406:
/bin/../include/c++/v1/cstddef:45:15: fatal error: 'stddef.h' file not
#include_next <stddef.h>
1 error generated.

I'm scratching my hair trying to understand what is wrong and what
should I do here.

Also, I can't understand why CMake adds all these -isystem include
directories. But this is a webkit issue I guess.

Any ideas/recommandations are welcome.

Kind regards,


More information about the llvm-dev mailing list