Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 4 Jun 2017 03:40:57 +0100
From: Aidan Hobson Sayers <>
Subject: Re: Re: [PATCH 1/1] Use compiler includes for musl-clang, like musl-gcc

It was pointed out to me that it's not clear why this is the correct fix
for the problem, so I'll elaborate a bit.

First, it's useful to note the (working and likely well-tested) musl-gcc
wrapper specs file [0], with this line of interest:

-nostdinc -isystem $incdir -isystem include%s

`-nostdinc` throws away all default include directories. The following
`-isystem` arguments then add the musl includes directory, and re-add the
compiler builtins include directory. Here are the expanded arguments when
compiling my example C file with `musl-gcc -v x.c`:

-nostdinc -isystem /tmp/tmp.TG88Sa26oT/musl/prefix/include -isystem

Clang does not have an equivalent of specs file, so it uses a shell script
[1]. The arguments corresponding to the gcc ones above are:

    -nostdinc \
    --sysroot "$libc" \
    -isystem "$libc_inc"

This does *not* re-add the compiler builtins include directory and so some
headers are inaccessible (this possibly hasn't come up before because
commonly-used builtins like stdbool.h are also present in the musl include
directory, leaving effectively just unwind.h and intrinsics as

By altering `-nostdinc` to -nostdlibinc`, the compiler builtins are never
removed from the include directories. Although I can't find any
documentation for the priority builtins have, it's logical that they would
come last and that's backed up by the include list produced by
`./musl/prefix/bin/musl-clang -Wp,-v -E - </dev/null` after applying my

#include <...> search starts here:

Without my patch, the `/usr/lib/llvm-3.8/bin/../lib/clang/3.8.0/include`
directory is not present. For completeness, here's the musl-gcc output

#include <...> search starts here:


On 29 October 2016 at 12:49, Aidan Hobson Sayers <> wrote:

> On 6 July 2016 at 18:44, Rich Felker <> wrote:
>> What happens when you #include <stddef.h> after making this change? Do
>> you get the compiler-provided one or musl's? You should be able to
>> tell by running musl-clang -E foo.c
> Wondering where this patch is up to?
> Per my (terse) previous response, stddef seems to be picked up from musl,
> which I think is the correct behaviour.

Content of type "text/html" skipped

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.