Re: Re: [PATCH 1/1] Use compiler includes for musl-clang, like musl-gcc

[Aidan Hobson Sayers <aidanhs@cantab.net>]

[-- Attachment #1: Type: text/plain, Size: 2647 bytes --]

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
/usr/lib/gcc/x86_64-linux-gnu/5/include


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
inaccessible).

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
patch:

#include <...> search starts here:
 /tmp/tmp.TG88Sa26oT/musl/prefix/include
 /usr/lib/llvm-3.8/bin/../lib/clang/3.8.0/include


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
snippet:

#include <...> search starts here:
 /tmp/tmp.TG88Sa26oT/musl/prefix/include
 /usr/lib/gcc/x86_64-linux-gnu/5/include


[0]
https://git.musl-libc.org/cgit/musl/tree/tools/musl-gcc.specs.sh?id=179766aa2ef06df854bc1d9616bf6f00ce49b7f9
[1]
https://git.musl-libc.org/cgit/musl/tree/tools/musl-clang.in?id=179766aa2ef06df854bc1d9616bf6f00ce49b7f9

On 29 October 2016 at 12:49, Aidan Hobson Sayers <aidanhs@cantab.net> wrote:

> On 6 July 2016 at 18:44, Rich Felker <dalias@libc.org> 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.
>

[-- Attachment #2: Type: text/html, Size: 4623 bytes --]