[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CA+jXYnRFMFGW8jLM=Qp0r+Bp6E8M2_YMaUm0xJL2z1Y5j6h4dQ@mail.gmail.com>
Date: Sun, 4 Jun 2017 03:40:57 +0100
From: Aidan Hobson Sayers <aidanhs@...tab.net>
To: musl@...ts.openwall.com
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
/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@...tab.net> wrote:
> On 6 July 2016 at 18:44, Rich Felker <dalias@...c.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.
>
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.
