[PATCH] When building, don't use flags which cause compiler warning

[PATCH] When building, don't use flags which cause compiler warning

[Alex Dowad]

A number of gcc flags are ignored by clang, and it prints annoying warnings
to let you know. There is no reason to use these flags with a compiler which
doesn't support them.
---

Dear muslers,

Not sure what you'll think of this... but please have a look.

Thanks,
Alex Dowad

 configure | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index cf9227a..30daa97 100755
--- a/configure
+++ b/configure
@@ -80,11 +80,16 @@ fi
 tryflag () {
 printf "checking whether compiler accepts %s... " "$2"
 echo "typedef int x;" > "$tmpc"
-if $CC $2 -c -o /dev/null "$tmpc" >/dev/null 2>&1 ; then
-printf "yes\n"
-eval "$1=\"\${$1} \$2\""
-eval "$1=\${$1# }"
-return 0
+if output=$($CC $2 -c -o /dev/null "$tmpc" 2>&1) ; then
+  if fnmatch '*warning*' "$output"; then
+    printf "disabled due to compiler warning\n"
+    return 1
+  else
+    printf "yes\n"
+    eval "$1=\"\${$1} \$2\""
+    eval "$1=\${$1# }"
+    return 0
+  fi
 else
 printf "no\n"
 return 1
-- 
2.0.0.GIT

Re: [PATCH] When building, don't use flags which cause compiler warning

[Rich Felker]

On Tue, May 26, 2015 at 07:51:34PM +0200, Alex Dowad wrote:
> A number of gcc flags are ignored by clang, and it prints annoying warnings
> to let you know. There is no reason to use these flags with a compiler which
> doesn't support them.
> ---
> 
> Dear muslers,
> 
> Not sure what you'll think of this... but please have a look.
> 
> Thanks,
> Alex Dowad
> 
>  configure | 15 ++++++++++-----
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/configure b/configure
> index cf9227a..30daa97 100755
> --- a/configure
> +++ b/configure
> @@ -80,11 +80,16 @@ fi
>  tryflag () {
>  printf "checking whether compiler accepts %s... " "$2"
>  echo "typedef int x;" > "$tmpc"
> -if $CC $2 -c -o /dev/null "$tmpc" >/dev/null 2>&1 ; then
> -printf "yes\n"
> -eval "$1=\"\${$1} \$2\""
> -eval "$1=\${$1# }"
> -return 0
> +if output=$($CC $2 -c -o /dev/null "$tmpc" 2>&1) ; then
> +  if fnmatch '*warning*' "$output"; then
> +    printf "disabled due to compiler warning\n"
> +    return 1
> +  else
> +    printf "yes\n"
> +    eval "$1=\"\${$1} \$2\""
> +    eval "$1=\${$1# }"
> +    return 0
> +  fi
>  else
>  printf "no\n"
>  return 1

I don't like parsing output rather than relying on exit status unless
it's for a really important purpose. The above is dangerous and could
break detection of options we actually need if a spurious warning
somehow arises, which is really common on alternate compilers that add
all sorts of warnings by default. Is there any way to convince clang
to error out on unknown options? Perhaps something like
-Werror=unknown-options?

Rich

[PATCH v2] When building, don't use compiler flags which cause warnings

[Alex Dowad]

This silences some warnings when building with clang.
---
Dear Rich Felker,

This accomplishes the same thing as the previous patch by "promoting" all
warnings to errors. Look better?

Thanks,
Alex Dowad

 configure | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index cf9227a..bca2bd9 100755
--- a/configure
+++ b/configure
@@ -80,7 +80,7 @@ fi
 tryflag () {
 printf "checking whether compiler accepts %s... " "$2"
 echo "typedef int x;" > "$tmpc"
-if $CC $2 -c -o /dev/null "$tmpc" >/dev/null 2>&1 ; then
+if $CC $2 -Werror -c -o /dev/null "$tmpc" >/dev/null 2>&1 ; then
 printf "yes\n"
 eval "$1=\"\${$1} \$2\""
 eval "$1=\${$1# }"
@@ -94,7 +94,7 @@ fi
 tryldflag () {
 printf "checking whether linker accepts %s... " "$2"
 echo "typedef int x;" > "$tmpc"
-if $CC -nostdlib -shared "$2" -o /dev/null "$tmpc" >/dev/null 2>&1 ; then
+if $CC -Werror -nostdlib -shared "$2" -o /dev/null "$tmpc" >/dev/null 2>&1 ; then
 printf "yes\n"
 eval "$1=\"\${$1} \$2\""
 eval "$1=\${$1# }"
-- 
2.0.0.GIT

Re: [PATCH v2] When building, don't use compiler flags which cause warnings

[Rich Felker]

On Tue, May 26, 2015 at 08:36:45PM +0200, Alex Dowad wrote:
> This silences some warnings when building with clang.
> ---
> Dear Rich Felker,
> 
> This accomplishes the same thing as the previous patch by "promoting" all
> warnings to errors. Look better?

No, it has exactly the same problem -- it treats any spurious warnings
which the chosen $CC might produce as a failure of the test.

Rich

Re: [PATCH v2] When building, don't use compiler flags which cause warnings

[Alex Dowad]

On 26/05/15 20:47, Rich Felker wrote:
> On Tue, May 26, 2015 at 08:36:45PM +0200, Alex Dowad wrote:
>> This silences some warnings when building with clang.
>> ---
>> Dear Rich Felker,
>>
>> This accomplishes the same thing as the previous patch by "promoting" all
>> warnings to errors. Look better?
> No, it has exactly the same problem -- it treats any spurious warnings
> which the chosen $CC might produce as a failure of the test.
OK, understood. It doesn't look like there is any way to treat ignored 
options as errors,
unfortunately.

Thanks for reviewing the patches, AD

Re: [PATCH v2] When building, don't use compiler flags which cause warnings

[Rich Felker]

On Tue, May 26, 2015 at 08:55:19PM +0200, Alex Dowad wrote:
> 
> 
> On 26/05/15 20:47, Rich Felker wrote:
> >On Tue, May 26, 2015 at 08:36:45PM +0200, Alex Dowad wrote:
> >>This silences some warnings when building with clang.
> >>---
> >>Dear Rich Felker,
> >>
> >>This accomplishes the same thing as the previous patch by "promoting" all
> >>warnings to errors. Look better?
> >No, it has exactly the same problem -- it treats any spurious warnings
> >which the chosen $CC might produce as a failure of the test.
> OK, understood. It doesn't look like there is any way to treat
> ignored options as errors,
> unfortunately.

Which flags are giving the warnings? I see both clang and cparser have
a -Wunknown-warning-option which gives warnings for unknown warning
options. I believe it's on by default, and could be turned off, but
using -Werrror=unknown-warning-option seems like the best thing to do
(so they get rejected). I don't see a way to disable warnings for
other unrecognized options, though.

Rich

Re: [PATCH v2] When building, don't use compiler flags which cause warnings

[Alex Dowad]

On 26/05/15 21:36, Rich Felker wrote:
> On Tue, May 26, 2015 at 08:55:19PM +0200, Alex Dowad wrote:
>>
>> On 26/05/15 20:47, Rich Felker wrote:
>>> On Tue, May 26, 2015 at 08:36:45PM +0200, Alex Dowad wrote:
>>>> This silences some warnings when building with clang.
>>>> ---
>>>> Dear Rich Felker,
>>>>
>>>> This accomplishes the same thing as the previous patch by "promoting" all
>>>> warnings to errors. Look better?
>>> No, it has exactly the same problem -- it treats any spurious warnings
>>> which the chosen $CC might produce as a failure of the test.
>> OK, understood. It doesn't look like there is any way to treat
>> ignored options as errors,
>> unfortunately.
> Which flags are giving the warnings? I see both clang and cparser have
> a -Wunknown-warning-option which gives warnings for unknown warning
> options. I believe it's on by default, and could be turned off, but
> using -Werrror=unknown-warning-option seems like the best thing to do
> (so they get rejected). I don't see a way to disable warnings for
> other unrecognized options, though.
Hmm. -Werror=unknown-warning-option causes configure to disable 
-Wno-unused-but-set-variable.
But it doesn't do anything for other ignored options. It causes problems 
when building with
gcc as well.

This isn't a big issue; I'd suggest it's better not to get stuck on it.

Thanks, AD

Re: [PATCH v2] When building, don't use compiler flags which cause warnings

[Shiz]

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

> On 26 May 2015, at 21:57, Alex Dowad <alexinbeijing@gmail.com> wrote:
> 
> 
> 
> On 26/05/15 21:36, Rich Felker wrote:
> Hmm. -Werror=unknown-warning-option causes configure to disable -Wno-unused-but-set-variable.
> But it doesn't do anything for other ignored options. It causes problems when building with
> gcc as well.
> 
> This isn't a big issue; I'd suggest it's better not to get stuck on it.
> 
> Thanks, AD

clang also has -Werror=unused-command-line-argument, which I imagine would work better,
possibly in tandem with -Werror=unknown-warning option if those gcc problems can be weeded out.

-S

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v2] When building, don't use compiler flags which cause warnings

[Rich Felker]

On Wed, May 27, 2015 at 04:22:59AM +0200, Shiz wrote:
> > On 26 May 2015, at 21:57, Alex Dowad <alexinbeijing@gmail.com> wrote:
> > 
> > 
> > 
> > On 26/05/15 21:36, Rich Felker wrote:
> > Hmm. -Werror=unknown-warning-option causes configure to disable -Wno-unused-but-set-variable.
> > But it doesn't do anything for other ignored options. It causes problems when building with
> > gcc as well.
> > 
> > This isn't a big issue; I'd suggest it's better not to get stuck on it.
> > 
> > Thanks, AD
> 
> clang also has -Werror=unused-command-line-argument, which I imagine would work better,

I think we _don't_ want this in our final CFLAGS (in fact we may want
the opposite, Wno-...) because it will probably error out on linker
options in CFLAGS or C compiler options in assembler invocations.

But if it detects unknown options, we could use it just at configure
time (if it's supported) to help determine when options are not
supported.

> possibly in tandem with -Werror=unknown-warning option if those gcc problems can be weeded out.

Yes.

Rich

Re: [PATCH v2] When building, don't use compiler flags which cause warnings

[Shiz]

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

> On 27 May 2015, at 05:14, Rich Felker <dalias@libc.org> wrote:
> 
> I think we _don't_ want this in our final CFLAGS (in fact we may want
> the opposite, Wno-...) because it will probably error out on linker
> options in CFLAGS or C compiler options in assembler invocations.
> 
> But if it detects unknown options, we could use it just at configure
> time (if it's supported) to help determine when options are not
> supported.

Yes, that is what I intended.

-S

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]