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 , 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 . 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  https://git.musl-libc.org/cgit/musl/tree/tools/musl-gcc.specs.sh?id=179766aa2ef06df854bc1d9616bf6f00ce49b7f9  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.