[PATCH] gdbsupport: better detection of -Wmissing-prototypes support

[PATCH] gdbsupport: better detection of -Wmissing-prototypes support

[Andrew Burgess]

When building with GCC 9.3.1 I notice lots of warnings like this while
building GDB:

  cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++

This is a little strange as the configure macro, AM_GDB_WARNINGS,
should figure out which warning flags are valid, and which are not.

It turns out that there's a weird bug in some older version of GCC;
when performing only a compile, the -Wmissing-prototypes flag will
only ever produce a warning, even when -Werror is passed.  If a full
compile and link is performed then an error is produced (assuming
-Werror is passed).

Of course, the AM_GDB_WARNINGS macro only tests each flag during a
compile, not a compile and link, so the macro figures that the
-Wmissing-prototypes flag is valid (even though a warning is emitted),
and adds it to the set of flags to use.

In this commit I special case the -Wmissing-prototypes check inside
AM_GDB_WARNINGS, and for that flag only, we now perform a full compile
and link.  This means that the configure script can correctly detect
that the flag is not supported, and so the flag is no longer used.
---
 gdb/configure         | 25 +++++++++++++++++++++++++
 gdbserver/configure   | 25 +++++++++++++++++++++++++
 gdbsupport/configure  | 25 +++++++++++++++++++++++++
 gdbsupport/warning.m4 | 14 ++++++++++++++
 4 files changed, 89 insertions(+)

diff --git a/gdb/configure b/gdb/configure
index f0b1af4a6ea..1bd9a7698b7 100755
--- a/gdb/configure
+++ b/gdb/configure
@@ -17016,6 +17016,31 @@ if ac_fn_cxx_try_compile "$LINENO"; then :
   WARN_CFLAGS="${WARN_CFLAGS} $w"
 fi
 rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+            elif test "x$w" = "x-Wmissing-prototypes"; then
+              # On some versions of GCC, e.g. 9.3.1, even when -Werror
+              # is passed, the -Wmissing-prototypes flag will only
+              # ever produce a warning when compiling, but, will
+              # produce an error when a full link is performed.  This
+              # bug is fixed in later versions of GCC.
+              #
+              # To avoid this bug, and detect if -Wmissing-prototypes
+              # is supported, we do a compile and link here.
+	      cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+int
+main ()
+{
+
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_cxx_try_link "$LINENO"; then :
+  WARN_CFLAGS="${WARN_CFLAGS} $w"
+fi
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
 	    else
 	      cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
diff --git a/gdbserver/configure b/gdbserver/configure
index b227167e270..c12354f583c 100755
--- a/gdbserver/configure
+++ b/gdbserver/configure
@@ -9766,6 +9766,31 @@ if ac_fn_cxx_try_compile "$LINENO"; then :
   WARN_CFLAGS="${WARN_CFLAGS} $w"
 fi
 rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+            elif test "x$w" = "x-Wmissing-prototypes"; then
+              # On some versions of GCC, e.g. 9.3.1, even when -Werror
+              # is passed, the -Wmissing-prototypes flag will only
+              # ever produce a warning when compiling, but, will
+              # produce an error when a full link is performed.  This
+              # bug is fixed in later versions of GCC.
+              #
+              # To avoid this bug, and detect if -Wmissing-prototypes
+              # is supported, we do a compile and link here.
+	      cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+int
+main ()
+{
+
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_cxx_try_link "$LINENO"; then :
+  WARN_CFLAGS="${WARN_CFLAGS} $w"
+fi
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
 	    else
 	      cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
diff --git a/gdbsupport/configure b/gdbsupport/configure
index a9dd02c5b72..ff8eb517d9e 100755
--- a/gdbsupport/configure
+++ b/gdbsupport/configure
@@ -10251,6 +10251,31 @@ if ac_fn_cxx_try_compile "$LINENO"; then :
   WARN_CFLAGS="${WARN_CFLAGS} $w"
 fi
 rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+            elif test "x$w" = "x-Wmissing-prototypes"; then
+              # On some versions of GCC, e.g. 9.3.1, even when -Werror
+              # is passed, the -Wmissing-prototypes flag will only
+              # ever produce a warning when compiling, but, will
+              # produce an error when a full link is performed.  This
+              # bug is fixed in later versions of GCC.
+              #
+              # To avoid this bug, and detect if -Wmissing-prototypes
+              # is supported, we do a compile and link here.
+	      cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+int
+main ()
+{
+
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_cxx_try_link "$LINENO"; then :
+  WARN_CFLAGS="${WARN_CFLAGS} $w"
+fi
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
 	    else
 	      cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
diff --git a/gdbsupport/warning.m4 b/gdbsupport/warning.m4
index 46036fa461e..7bb8176b50f 100644
--- a/gdbsupport/warning.m4
+++ b/gdbsupport/warning.m4
@@ -150,6 +150,20 @@ then
 		[WARN_CFLAGS="${WARN_CFLAGS} $w"],
 		[]
 	      )
+            elif test "x$w" = "x-Wmissing-prototypes"; then
+              # On some versions of GCC, e.g. 9.3.1, even when -Werror
+              # is passed, the -Wmissing-prototypes flag will only
+              # ever produce a warning when compiling, but, will
+              # produce an error when a full link is performed.  This
+              # bug is fixed in later versions of GCC.
+              #
+              # To avoid this bug, and detect if -Wmissing-prototypes
+              # is supported, we do a compile and link here.
+	      AC_LINK_IFELSE(
+		[AC_LANG_PROGRAM([],[])],
+		[WARN_CFLAGS="${WARN_CFLAGS} $w"],
+		[]
+	      )
 	    else
 	      AC_COMPILE_IFELSE(
 		[AC_LANG_PROGRAM([], [])],
-- 
2.25.4

Re: [PATCH] gdbsupport: better detection of -Wmissing-prototypes support

[Andrew Burgess]

* Andrew Burgess <andrew.burgess@embecosm.com> [2021-09-24 13:29:33 +0100]:

> When building with GCC 9.3.1 I notice lots of warnings like this while
> building GDB:
> 
>   cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++
> 
> This is a little strange as the configure macro, AM_GDB_WARNINGS,
> should figure out which warning flags are valid, and which are not.
> 
> It turns out that there's a weird bug in some older version of GCC;
> when performing only a compile, the -Wmissing-prototypes flag will
> only ever produce a warning, even when -Werror is passed.  If a full
> compile and link is performed then an error is produced (assuming
> -Werror is passed).
> 
> Of course, the AM_GDB_WARNINGS macro only tests each flag during a
> compile, not a compile and link, so the macro figures that the
> -Wmissing-prototypes flag is valid (even though a warning is emitted),
> and adds it to the set of flags to use.
> 
> In this commit I special case the -Wmissing-prototypes check inside
> AM_GDB_WARNINGS, and for that flag only, we now perform a full compile
> and link.  This means that the configure script can correctly detect
> that the flag is not supported, and so the flag is no longer used.

It has been pointed out to me on IRC (thanks Simon), that this issue
is not GCC, but ccache:

  https://github.com/ccache/ccache/issues/738#issuecomment-740133374

So this patch certainly shouldn't go in as it is currently written.

It's still pretty annoying seeing those warnings though, so I wonder
if we can consider having a work around for this ccache issue in the
GDB configure scripts?

Maybe something as simple as setting CCACHE_DISABLE in the environment
prior to running the AM_GDB_WARNINGS checks?

All ideas welcome...

thanks,
Andrewx


> ---
>  gdb/configure         | 25 +++++++++++++++++++++++++
>  gdbserver/configure   | 25 +++++++++++++++++++++++++
>  gdbsupport/configure  | 25 +++++++++++++++++++++++++
>  gdbsupport/warning.m4 | 14 ++++++++++++++
>  4 files changed, 89 insertions(+)
> 
> diff --git a/gdb/configure b/gdb/configure
> index f0b1af4a6ea..1bd9a7698b7 100755
> --- a/gdb/configure
> +++ b/gdb/configure
> @@ -17016,6 +17016,31 @@ if ac_fn_cxx_try_compile "$LINENO"; then :
>    WARN_CFLAGS="${WARN_CFLAGS} $w"
>  fi
>  rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
> +            elif test "x$w" = "x-Wmissing-prototypes"; then
> +              # On some versions of GCC, e.g. 9.3.1, even when -Werror
> +              # is passed, the -Wmissing-prototypes flag will only
> +              # ever produce a warning when compiling, but, will
> +              # produce an error when a full link is performed.  This
> +              # bug is fixed in later versions of GCC.
> +              #
> +              # To avoid this bug, and detect if -Wmissing-prototypes
> +              # is supported, we do a compile and link here.
> +	      cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> +/* end confdefs.h.  */
> +
> +int
> +main ()
> +{
> +
> +  ;
> +  return 0;
> +}
> +_ACEOF
> +if ac_fn_cxx_try_link "$LINENO"; then :
> +  WARN_CFLAGS="${WARN_CFLAGS} $w"
> +fi
> +rm -f core conftest.err conftest.$ac_objext \
> +    conftest$ac_exeext conftest.$ac_ext
>  	    else
>  	      cat confdefs.h - <<_ACEOF >conftest.$ac_ext
>  /* end confdefs.h.  */
> diff --git a/gdbserver/configure b/gdbserver/configure
> index b227167e270..c12354f583c 100755
> --- a/gdbserver/configure
> +++ b/gdbserver/configure
> @@ -9766,6 +9766,31 @@ if ac_fn_cxx_try_compile "$LINENO"; then :
>    WARN_CFLAGS="${WARN_CFLAGS} $w"
>  fi
>  rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
> +            elif test "x$w" = "x-Wmissing-prototypes"; then
> +              # On some versions of GCC, e.g. 9.3.1, even when -Werror
> +              # is passed, the -Wmissing-prototypes flag will only
> +              # ever produce a warning when compiling, but, will
> +              # produce an error when a full link is performed.  This
> +              # bug is fixed in later versions of GCC.
> +              #
> +              # To avoid this bug, and detect if -Wmissing-prototypes
> +              # is supported, we do a compile and link here.
> +	      cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> +/* end confdefs.h.  */
> +
> +int
> +main ()
> +{
> +
> +  ;
> +  return 0;
> +}
> +_ACEOF
> +if ac_fn_cxx_try_link "$LINENO"; then :
> +  WARN_CFLAGS="${WARN_CFLAGS} $w"
> +fi
> +rm -f core conftest.err conftest.$ac_objext \
> +    conftest$ac_exeext conftest.$ac_ext
>  	    else
>  	      cat confdefs.h - <<_ACEOF >conftest.$ac_ext
>  /* end confdefs.h.  */
> diff --git a/gdbsupport/configure b/gdbsupport/configure
> index a9dd02c5b72..ff8eb517d9e 100755
> --- a/gdbsupport/configure
> +++ b/gdbsupport/configure
> @@ -10251,6 +10251,31 @@ if ac_fn_cxx_try_compile "$LINENO"; then :
>    WARN_CFLAGS="${WARN_CFLAGS} $w"
>  fi
>  rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
> +            elif test "x$w" = "x-Wmissing-prototypes"; then
> +              # On some versions of GCC, e.g. 9.3.1, even when -Werror
> +              # is passed, the -Wmissing-prototypes flag will only
> +              # ever produce a warning when compiling, but, will
> +              # produce an error when a full link is performed.  This
> +              # bug is fixed in later versions of GCC.
> +              #
> +              # To avoid this bug, and detect if -Wmissing-prototypes
> +              # is supported, we do a compile and link here.
> +	      cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> +/* end confdefs.h.  */
> +
> +int
> +main ()
> +{
> +
> +  ;
> +  return 0;
> +}
> +_ACEOF
> +if ac_fn_cxx_try_link "$LINENO"; then :
> +  WARN_CFLAGS="${WARN_CFLAGS} $w"
> +fi
> +rm -f core conftest.err conftest.$ac_objext \
> +    conftest$ac_exeext conftest.$ac_ext
>  	    else
>  	      cat confdefs.h - <<_ACEOF >conftest.$ac_ext
>  /* end confdefs.h.  */
> diff --git a/gdbsupport/warning.m4 b/gdbsupport/warning.m4
> index 46036fa461e..7bb8176b50f 100644
> --- a/gdbsupport/warning.m4
> +++ b/gdbsupport/warning.m4
> @@ -150,6 +150,20 @@ then
>  		[WARN_CFLAGS="${WARN_CFLAGS} $w"],
>  		[]
>  	      )
> +            elif test "x$w" = "x-Wmissing-prototypes"; then
> +              # On some versions of GCC, e.g. 9.3.1, even when -Werror
> +              # is passed, the -Wmissing-prototypes flag will only
> +              # ever produce a warning when compiling, but, will
> +              # produce an error when a full link is performed.  This
> +              # bug is fixed in later versions of GCC.
> +              #
> +              # To avoid this bug, and detect if -Wmissing-prototypes
> +              # is supported, we do a compile and link here.
> +	      AC_LINK_IFELSE(
> +		[AC_LANG_PROGRAM([],[])],
> +		[WARN_CFLAGS="${WARN_CFLAGS} $w"],
> +		[]
> +	      )
>  	    else
>  	      AC_COMPILE_IFELSE(
>  		[AC_LANG_PROGRAM([], [])],
> -- 
> 2.25.4
> 

Re: [PATCH] gdbsupport: better detection of -Wmissing-prototypes support

[Simon Marchi]

On 2021-09-24 9:16 a.m., Andrew Burgess wrote:
> It has been pointed out to me on IRC (thanks Simon), that this issue
> is not GCC, but ccache:
> 
>   https://github.com/ccache/ccache/issues/738#issuecomment-740133374
> 
> So this patch certainly shouldn't go in as it is currently written.
> 
> It's still pretty annoying seeing those warnings though, so I wonder
> if we can consider having a work around for this ccache issue in the
> GDB configure scripts?
> 
> Maybe something as simple as setting CCACHE_DISABLE in the environment
> prior to running the AM_GDB_WARNINGS checks?
> 
> All ideas welcome...

Either way would be fine with me:

 - to use AC_LINK_IFELSE all the time (I don't think the execution time
   would be significantly higher)
 - to set CCACHE_DISABLE during the execution of AM_GDB_WARNINGS

Simon

Re: [PATCH] gdbsupport: better detection of -Wmissing-prototypes support

[Pedro Alves]

On 2021-09-24 2:40 p.m., Simon Marchi via Gdb-patches wrote:
> On 2021-09-24 9:16 a.m., Andrew Burgess wrote:
>> It has been pointed out to me on IRC (thanks Simon), that this issue
>> is not GCC, but ccache:
>>
>>   https://github.com/ccache/ccache/issues/738#issuecomment-740133374
>>
>> So this patch certainly shouldn't go in as it is currently written.
>>
>> It's still pretty annoying seeing those warnings though, so I wonder
>> if we can consider having a work around for this ccache issue in the
>> GDB configure scripts?
>>
>> Maybe something as simple as setting CCACHE_DISABLE in the environment
>> prior to running the AM_GDB_WARNINGS checks?
>>
>> All ideas welcome...
> 
> Either way would be fine with me:
> 
>  - to use AC_LINK_IFELSE all the time (I don't think the execution time
>    would be significantly higher)
>  - to set CCACHE_DISABLE during the execution of AM_GDB_WARNINGS

Does working around this in configure tests still mean that when using ccache
for really building gdb, ccache will still misreorder arguments and thus
potentially a -Wmissing-prototypes warning would not be turned into an error?

So, here's another option, I think:

#3 - drop -Wmissing-prototypes completely.

As the GCC warning says,

  cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++

it's only valid for C, not C++.  Do we compile anything with a C compiler nowadays?

Re: [PATCH] gdbsupport: better detection of -Wmissing-prototypes support

[Simon Marchi]

On 2021-09-24 10:06 a.m., Pedro Alves wrote:
> On 2021-09-24 2:40 p.m., Simon Marchi via Gdb-patches wrote:
>> On 2021-09-24 9:16 a.m., Andrew Burgess wrote:
>>> It has been pointed out to me on IRC (thanks Simon), that this issue
>>> is not GCC, but ccache:
>>>
>>>   https://github.com/ccache/ccache/issues/738#issuecomment-740133374
>>>
>>> So this patch certainly shouldn't go in as it is currently written.
>>>
>>> It's still pretty annoying seeing those warnings though, so I wonder
>>> if we can consider having a work around for this ccache issue in the
>>> GDB configure scripts?
>>>
>>> Maybe something as simple as setting CCACHE_DISABLE in the environment
>>> prior to running the AM_GDB_WARNINGS checks?
>>>
>>> All ideas welcome...
>>
>> Either way would be fine with me:
>>
>>  - to use AC_LINK_IFELSE all the time (I don't think the execution time
>>    would be significantly higher)
>>  - to set CCACHE_DISABLE during the execution of AM_GDB_WARNINGS
> 
> Does working around this in configure tests still mean that when using ccache
> for really building gdb, ccache will still misreorder arguments and thus
> potentially a -Wmissing-prototypes warning would not be turned into an error?

I think it's only the "-Wmissing-prototypes is useless in C++" warning
that has this order problem.  If you were compiling something in C and
was missing a prototype, that warning would be not be affected by the
order bug (although I haven't tried).

By working around in the problem in configure, that means
-Wmissing-prototypes will not be present when compiling with GCC (as it
does nothing in C++), so there's nothing to miss here.

> So, here's another option, I think:
> 
> #3 - drop -Wmissing-prototypes completely.
> 
> As the GCC warning says,
> 
>   cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++
> 
> it's only valid for C, not C++.  Do we compile anything with a C compiler nowadays?

It's there because it does something for clang in C++, see:

  https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=a0761e34f054767de6d6389929d27e9015fb299b

If we find that the rationale for having it there isn't valid anymore,
we can remove it.

Simon

Re: [PATCH] gdbsupport: better detection of -Wmissing-prototypes support

[Pedro Alves]

On 2021-09-24 3:22 p.m., Simon Marchi wrote:
> 
> 
> On 2021-09-24 10:06 a.m., Pedro Alves wrote:
>> On 2021-09-24 2:40 p.m., Simon Marchi via Gdb-patches wrote:
>>> On 2021-09-24 9:16 a.m., Andrew Burgess wrote:
>>>> It has been pointed out to me on IRC (thanks Simon), that this issue
>>>> is not GCC, but ccache:
>>>>
>>>>   https://github.com/ccache/ccache/issues/738#issuecomment-740133374
>>>>
>>>> So this patch certainly shouldn't go in as it is currently written.
>>>>
>>>> It's still pretty annoying seeing those warnings though, so I wonder
>>>> if we can consider having a work around for this ccache issue in the
>>>> GDB configure scripts?
>>>>
>>>> Maybe something as simple as setting CCACHE_DISABLE in the environment
>>>> prior to running the AM_GDB_WARNINGS checks?
>>>>
>>>> All ideas welcome...
>>>
>>> Either way would be fine with me:
>>>
>>>  - to use AC_LINK_IFELSE all the time (I don't think the execution time
>>>    would be significantly higher)
>>>  - to set CCACHE_DISABLE during the execution of AM_GDB_WARNINGS
>>
>> Does working around this in configure tests still mean that when using ccache
>> for really building gdb, ccache will still misreorder arguments and thus
>> potentially a -Wmissing-prototypes warning would not be turned into an error?
> 
> I think it's only the "-Wmissing-prototypes is useless in C++" warning
> that has this order problem.  If you were compiling something in C and
> was missing a prototype, that warning would be not be affected by the
> order bug (although I haven't tried).
> 
> By working around in the problem in configure, that means
> -Wmissing-prototypes will not be present when compiling with GCC (as it
> does nothing in C++), so there's nothing to miss here.
> 
>> So, here's another option, I think:
>>
>> #3 - drop -Wmissing-prototypes completely.
>>
>> As the GCC warning says,
>>
>>   cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++
>>
>> it's only valid for C, not C++.  Do we compile anything with a C compiler nowadays?
> 
> It's there because it does something for clang in C++, see:
> 
>   https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=a0761e34f054767de6d6389929d27e9015fb299b
> 
> If we find that the rationale for having it there isn't valid anymore,
> we can remove it.

How about skipping checking for -Wmissing-prototypes support if compiling with gcc then?

Re: [PATCH] gdbsupport: better detection of -Wmissing-prototypes support

[Simon Marchi]

> How about skipping checking for -Wmissing-prototypes support if compiling with gcc then?

The other solutions seemed a bit better to me, since they were adding
less special cases and complexity, but in the end I don't really mind,
as long as it works.

Simon

Re: [PATCH] gdbsupport: better detection of -Wmissing-prototypes support

[Pedro Alves]

On 2021-09-24 3:55 p.m., Simon Marchi wrote:
>> How about skipping checking for -Wmissing-prototypes support if compiling with gcc then?
> 
> The other solutions seemed a bit better to me, since they were adding
> less special cases and complexity, but in the end I don't really mind,
> as long as it works.

Imagine two different sets of warnings, warnings about "bad1", and warnings about "bad2" with
"bad1" and "bad2" being completely unrelated.

You want to enable warnings about "bad1", and not about "bad2".  The problem is that both
compilers A and B accept a "-Wfoo" switch, and that switch enables "bad1" warnings on compiler A,
and "bad2" warnings on compiler B.

How do you handle this?  Well, the most obvious fix would be to make it compiler specific, right?

Forcing linking or doing something special for ccache seems like special casing to me too.
More than a compiler check from the angle above, from the view that not enabling the warning
on GCC is just something that makes sense on its own.

In the end I don't mind which approach is taken either.  Opinions were asked, and I gave mine.  :-)

[PATCHv2] gdbsupport: better detection of -Wmissing-prototypes support

[Andrew Burgess]

I know there's still some discussion about what the best way to deal
with this might be, but here's an updated patch that just uses
AM_LINK_IFELSE for all the AM_GDB_WARNINGS tests.

If the preference is for a different approach, I'm happy to go with
something else instead.

Thanks,
Andrew

---

When building using ccache I notice lots of warnings like this while
building GDB:

  cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++

This is a little strange as the configure macro, AM_GDB_WARNINGS,
should figure out which warning flags are valid, and which are not.

It turns out that there's an issue with ccache and gcc relating to
option ordering, these are described here:

  https://github.com/ccache/ccache/issues/738
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87161

Basically, ccache reorders some command line options, so this:

  -Werror -Wmissing-prototypes

becomes:

  -Wmissing-prototypes -Werror

And, so, when g++ sees the -Wmissing-prototypes option, it has not yet
seen -Werror, and as -Wmissing-prototypes is not supported in g++, a
warning is immediately issued.

What this means is that when the AM_GDB_WARNINGS macro tries to test
if -Wmissing-prototypes is support on g++ (and if the user is using
ccache), then all the macro ever sees is a warning, not an error, and
so the macro assumes that -Wmissing-prototypes is supported.

Now the AM_GDB_WARNINGS makes use of AM_COMPILE_IFELSE to compile a
test file to object format.  IF instead we use AM_LINK_IFELSE then the
compiler will be invoked to take the source file all the way to
executable format.

Now, when ccache sees the compiler invoked to do a full build (to
executable), ccache does not activate, and there is not command line
flag reordering, and so, we get an error for -Wmissing-prototypes
rather than a warning, and this flag will not be used (for g++).
---
 gdb/configure         | 26 ++++++++++++++++++++++----
 gdbserver/configure   | 26 ++++++++++++++++++++++----
 gdbsupport/configure  | 26 ++++++++++++++++++++++----
 gdbsupport/warning.m4 | 20 ++++++++++++++++++--
 4 files changed, 84 insertions(+), 14 deletions(-)

diff --git a/gdb/configure b/gdb/configure
index f0b1af4a6ea..41df4d22b88 100755
--- a/gdb/configure
+++ b/gdb/configure
@@ -16993,6 +16993,22 @@ $as_echo_n "checking compiler warning flags... " >&6; }
 	    CFLAGS="$CFLAGS -Werror $wtest"
 	    saved_CXXFLAGS="$CXXFLAGS"
 	    CXXFLAGS="$CXXFLAGS -Werror $wtest"
+            # In the following tests we use AC_LINK_IFELSE rather than
+            # AC_COMPILE_IFELSE, this works around this issue when
+            # using ccache: https://github.com/ccache/ccache/issues/738.
+            #
+            # Basically, ccache will reorder -Werror with respect to
+            # other command line options, placing -Werror after other
+            # options.  If the problem with the command line option is
+            # that it is not supported in the current language
+            # (e.g. -Wmissing-prototypes for g++), then this means
+            # that you'll get a warning and not an error about the
+            # option.
+            #
+            # However, if we perform a full link then ccache will not
+            # kick in (ccache only activates when compiling to object
+            # format), and so the options are not reordered, and we'll
+            # get an error for any unsupported options.
 	    if test "x$w" = "x-Wunused-variable"; then
 	      # Check for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38958,
 	      # fixed in GCC 4.9.  This test is derived from the gdb
@@ -17012,10 +17028,11 @@ const scoped_restore_base &b = scoped_restore_tmpl();
   return 0;
 }
 _ACEOF
-if ac_fn_cxx_try_compile "$LINENO"; then :
+if ac_fn_cxx_try_link "$LINENO"; then :
   WARN_CFLAGS="${WARN_CFLAGS} $w"
 fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
 	    else
 	      cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
@@ -17028,10 +17045,11 @@ main ()
   return 0;
 }
 _ACEOF
-if ac_fn_cxx_try_compile "$LINENO"; then :
+if ac_fn_cxx_try_link "$LINENO"; then :
   WARN_CFLAGS="${WARN_CFLAGS} $w"
 fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
 	    fi
 	    CFLAGS="$saved_CFLAGS"
 	    CXXFLAGS="$saved_CXXFLAGS"
diff --git a/gdbserver/configure b/gdbserver/configure
index b227167e270..23f1fc4d022 100755
--- a/gdbserver/configure
+++ b/gdbserver/configure
@@ -9743,6 +9743,22 @@ $as_echo_n "checking compiler warning flags... " >&6; }
 	    CFLAGS="$CFLAGS -Werror $wtest"
 	    saved_CXXFLAGS="$CXXFLAGS"
 	    CXXFLAGS="$CXXFLAGS -Werror $wtest"
+            # In the following tests we use AC_LINK_IFELSE rather than
+            # AC_COMPILE_IFELSE, this works around this issue when
+            # using ccache: https://github.com/ccache/ccache/issues/738.
+            #
+            # Basically, ccache will reorder -Werror with respect to
+            # other command line options, placing -Werror after other
+            # options.  If the problem with the command line option is
+            # that it is not supported in the current language
+            # (e.g. -Wmissing-prototypes for g++), then this means
+            # that you'll get a warning and not an error about the
+            # option.
+            #
+            # However, if we perform a full link then ccache will not
+            # kick in (ccache only activates when compiling to object
+            # format), and so the options are not reordered, and we'll
+            # get an error for any unsupported options.
 	    if test "x$w" = "x-Wunused-variable"; then
 	      # Check for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38958,
 	      # fixed in GCC 4.9.  This test is derived from the gdb
@@ -9762,10 +9778,11 @@ const scoped_restore_base &b = scoped_restore_tmpl();
   return 0;
 }
 _ACEOF
-if ac_fn_cxx_try_compile "$LINENO"; then :
+if ac_fn_cxx_try_link "$LINENO"; then :
   WARN_CFLAGS="${WARN_CFLAGS} $w"
 fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
 	    else
 	      cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
@@ -9778,10 +9795,11 @@ main ()
   return 0;
 }
 _ACEOF
-if ac_fn_cxx_try_compile "$LINENO"; then :
+if ac_fn_cxx_try_link "$LINENO"; then :
   WARN_CFLAGS="${WARN_CFLAGS} $w"
 fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
 	    fi
 	    CFLAGS="$saved_CFLAGS"
 	    CXXFLAGS="$saved_CXXFLAGS"
diff --git a/gdbsupport/configure b/gdbsupport/configure
index a9dd02c5b72..43c7b06d135 100755
--- a/gdbsupport/configure
+++ b/gdbsupport/configure
@@ -10228,6 +10228,22 @@ $as_echo_n "checking compiler warning flags... " >&6; }
 	    CFLAGS="$CFLAGS -Werror $wtest"
 	    saved_CXXFLAGS="$CXXFLAGS"
 	    CXXFLAGS="$CXXFLAGS -Werror $wtest"
+            # In the following tests we use AC_LINK_IFELSE rather than
+            # AC_COMPILE_IFELSE, this works around this issue when
+            # using ccache: https://github.com/ccache/ccache/issues/738.
+            #
+            # Basically, ccache will reorder -Werror with respect to
+            # other command line options, placing -Werror after other
+            # options.  If the problem with the command line option is
+            # that it is not supported in the current language
+            # (e.g. -Wmissing-prototypes for g++), then this means
+            # that you'll get a warning and not an error about the
+            # option.
+            #
+            # However, if we perform a full link then ccache will not
+            # kick in (ccache only activates when compiling to object
+            # format), and so the options are not reordered, and we'll
+            # get an error for any unsupported options.
 	    if test "x$w" = "x-Wunused-variable"; then
 	      # Check for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38958,
 	      # fixed in GCC 4.9.  This test is derived from the gdb
@@ -10247,10 +10263,11 @@ const scoped_restore_base &b = scoped_restore_tmpl();
   return 0;
 }
 _ACEOF
-if ac_fn_cxx_try_compile "$LINENO"; then :
+if ac_fn_cxx_try_link "$LINENO"; then :
   WARN_CFLAGS="${WARN_CFLAGS} $w"
 fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
 	    else
 	      cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
@@ -10263,10 +10280,11 @@ main ()
   return 0;
 }
 _ACEOF
-if ac_fn_cxx_try_compile "$LINENO"; then :
+if ac_fn_cxx_try_link "$LINENO"; then :
   WARN_CFLAGS="${WARN_CFLAGS} $w"
 fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
 	    fi
 	    CFLAGS="$saved_CFLAGS"
 	    CXXFLAGS="$saved_CXXFLAGS"
diff --git a/gdbsupport/warning.m4 b/gdbsupport/warning.m4
index 46036fa461e..53dc59bc490 100644
--- a/gdbsupport/warning.m4
+++ b/gdbsupport/warning.m4
@@ -135,11 +135,27 @@ then
 	    CFLAGS="$CFLAGS -Werror $wtest"
 	    saved_CXXFLAGS="$CXXFLAGS"
 	    CXXFLAGS="$CXXFLAGS -Werror $wtest"
+            # In the following tests we use AC_LINK_IFELSE rather than
+            # AC_COMPILE_IFELSE, this works around this issue when
+            # using ccache: https://github.com/ccache/ccache/issues/738.
+            #
+            # Basically, ccache will reorder -Werror with respect to
+            # other command line options, placing -Werror after other
+            # options.  If the problem with the command line option is
+            # that it is not supported in the current language
+            # (e.g. -Wmissing-prototypes for g++), then this means
+            # that you'll get a warning and not an error about the
+            # option.
+            #
+            # However, if we perform a full link then ccache will not
+            # kick in (ccache only activates when compiling to object
+            # format), and so the options are not reordered, and we'll
+            # get an error for any unsupported options.
 	    if test "x$w" = "x-Wunused-variable"; then
 	      # Check for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38958,
 	      # fixed in GCC 4.9.  This test is derived from the gdb
 	      # source code that triggered this bug in GCC.
-	      AC_COMPILE_IFELSE(
+	      AC_LINK_IFELSE(
 		[AC_LANG_PROGRAM(
 		   [struct scoped_restore_base {};
 		    struct scoped_restore_tmpl : public scoped_restore_base {
@@ -151,7 +167,7 @@ then
 		[]
 	      )
 	    else
-	      AC_COMPILE_IFELSE(
+	      AC_LINK_IFELSE(
 		[AC_LANG_PROGRAM([], [])],
 		[WARN_CFLAGS="${WARN_CFLAGS} $w"],
 		[]
-- 
2.25.4

Re: [PATCHv2] gdbsupport: better detection of -Wmissing-prototypes support

[Simon Marchi]

On 2021-09-24 11:14, Andrew Burgess wrote:
> I know there's still some discussion about what the best way to deal
> with this might be, but here's an updated patch that just uses
> AM_LINK_IFELSE for all the AM_GDB_WARNINGS tests.
> 
> If the preference is for a different approach, I'm happy to go with
> something else instead.
> 
> Thanks,
> Andrew

Hi Andrew,

I just stumbled on this while scrolling my inbox.  I'd be happy for you
to merge any version of this :).

Simon