Patchwork [1/9] build: disable Wstrict-prototypes

login
register
mail settings
Submitter Anthony Liguori
Date Feb. 20, 2013, 1:43 p.m.
Message ID <1361367806-4599-2-git-send-email-aliguori@us.ibm.com>
Download mbox | patch
Permalink /patch/222086/
State New
Headers show

Comments

Anthony Liguori - Feb. 20, 2013, 1:43 p.m.
GTK won't build with strict-prototypes due to gtkitemfactory.h:

    /* We use () here to mean unspecified arguments. This is deprecated
     * as of C99, but we can't change it without breaking compatibility.
     * (Note that if we are included from a C++ program () will mean
     * (void) so an explicit cast will be needed.)
     */
    typedef	void	(*GtkItemFactoryCallback)  ();

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Peter Maydell - Feb. 20, 2013, 2:27 p.m.
On 20 February 2013 13:43, Anthony Liguori <aliguori@us.ibm.com> wrote:
> GTK won't build with strict-prototypes due to gtkitemfactory.h:
>
>     /* We use () here to mean unspecified arguments. This is deprecated
>      * as of C99, but we can't change it without breaking compatibility.
>      * (Note that if we are included from a C++ program () will mean
>      * (void) so an explicit cast will be needed.)
>      */
>     typedef     void    (*GtkItemFactoryCallback)  ();

Yuck. Consider wrapping the use of this header with gcc diagnostic
pragmas instead so we don't have to drop a perfectly good warning
flag for the sake of busted libraries?

-- PMM
Andreas Färber - Feb. 20, 2013, 3:40 p.m.
Am 20.02.2013 15:27, schrieb Peter Maydell:
> On 20 February 2013 13:43, Anthony Liguori <aliguori@us.ibm.com> wrote:
>> GTK won't build with strict-prototypes due to gtkitemfactory.h:
>>
>>     /* We use () here to mean unspecified arguments. This is deprecated
>>      * as of C99, but we can't change it without breaking compatibility.
>>      * (Note that if we are included from a C++ program () will mean
>>      * (void) so an explicit cast will be needed.)
>>      */
>>     typedef     void    (*GtkItemFactoryCallback)  ();
> 
> Yuck. Consider wrapping the use of this header with gcc diagnostic
> pragmas instead so we don't have to drop a perfectly good warning
> flag for the sake of busted libraries?

+1, same thought here. Would GCC diagnostics work for clang though?

Andreas

Patch

diff --git a/configure b/configure
index bf5970f..74d5878 100755
--- a/configure
+++ b/configure
@@ -283,7 +283,7 @@  sdl_config="${SDL_CONFIG-${cross_prefix}sdl-config}"
 # default flags for all hosts
 QEMU_CFLAGS="-fno-strict-aliasing $QEMU_CFLAGS"
 QEMU_CFLAGS="-Wall -Wundef -Wwrite-strings -Wmissing-prototypes $QEMU_CFLAGS"
-QEMU_CFLAGS="-Wstrict-prototypes -Wredundant-decls $QEMU_CFLAGS"
+QEMU_CFLAGS="-Wredundant-decls $QEMU_CFLAGS"
 QEMU_CFLAGS="-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE $QEMU_CFLAGS"
 QEMU_INCLUDES="-I. -I\$(SRC_PATH) -I\$(SRC_PATH)/include"
 if test "$debug_info" = "yes"; then