Thank you for the pointers. That helps.

Found out it was my fault.
When building musl, I set the --prefix=/usr

So in the project, althought I did pass a --sysroot, I also ended up
passing -I.../usr (where musl lives).

Once I sorted those out, the warnings disappears.

Thanks again.



On Tue, Jan 9, 2018 at 9:08 AM Rich Felker <dalias@libc.org> wrote:

> On Tue, Jan 09, 2018 at 06:01:49PM +0100, Markus Wichmann wrote:
> > On Tue, Jan 09, 2018 at 04:48:02PM +0000, Patrick Cheng wrote:
> > > Hello,
> > >
> > > Not sure if it's the version of clang that I was using, or the warning
> > > level/toggle on the project that I was compiling, but Musl headers were
> > > causing a number of warnings.
> > >
> > > Added extra parenthesis, so it's more explicit the precedence of | vs &
> > >
> > > Added 'const' to the typecasting. Clang didn't like const casting.
> > >
> >
> > Didn't we have this topic already? If clang reports warnings from system
> > headers, it is broken. Either because it is not told those headers are
> > from the system (did you use -I instead of -isystem?) or because clang
> > is broken fundamentally. The latter appears to be unlikely, but I've
> > seen horses puke before.
>
> Yes, musl policy is not to let compiler warning whims dictate the way
> code or headers are written, on the assumption that musl itself is
> built with the warning options it's intended to be used with, and that
> compilers do not generate warnings for system headers.
>
> As you noted, usually when this topic comes up it means the user has
> not installed musl correctly and is trying to manually -I it rather
> than using a musl-targeting toolchain or the provided wrapper scripts.
> So it tends to be a helpful warning that something else is wrong in
> the user's setup.
>
> Rich
>