mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Patrick Cheng <patrickyccheng@gmail.com>
To: musl@lists.openwall.com
Subject: Re: [Patch] reduced warnings reported by clang
Date: Tue, 09 Jan 2018 17:49:15 +0000	[thread overview]
Message-ID: <CAKb-6ju83qJqwbG5BYX-K4riSFZsp2JfW3FZ_qcwq+A7V1n_2g@mail.gmail.com> (raw)
In-Reply-To: <20180109170746.GV1627@brightrain.aerifal.cx>

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

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
>

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

      reply	other threads:[~2018-01-09 17:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-09 16:48 Patrick Cheng
2018-01-09 17:01 ` Markus Wichmann
2018-01-09 17:07   ` Rich Felker
2018-01-09 17:49     ` Patrick Cheng [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKb-6ju83qJqwbG5BYX-K4riSFZsp2JfW3FZ_qcwq+A7V1n_2g@mail.gmail.com \
    --to=patrickyccheng@gmail.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).