[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] build: Silence clang warning on older glib autoptr usage

From: Eric Blake
Subject: Re: [PATCH] build: Silence clang warning on older glib autoptr usage
Date: Wed, 18 Mar 2020 06:19:53 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0

On 3/17/20 1:11 PM, Peter Maydell wrote:
On Tue, 17 Mar 2020 at 17:55, Eric Blake <address@hidden> wrote:

glib's G_DEFINE_AUTOPTR_CLEANUP_FUNC() macro defines several static
inline functions, often with some of them unused, but prior to 2.57.2
did not mark the functions as such.  As a result, clang (but not gcc)
fails to build with older glib unless -Wno-unused-function is enabled.

Reported-by: Peter Maydell <address@hidden>
Signed-off-by: Eric Blake <address@hidden>

Half-tested: I proved to myself that this does NOT enable
-Wno-unused-function on my setup of glib 2.62.5 and gcc 9.2.1 (Fedora
31), but would do so if I introduced an intentional compile error into
the sample program; but Iwas unable to test that it would prevent the
build failure encountered by Peter on John's pull request (older glib
but exact version unknown, clang, on NetBSD).

This wasn't a NetBSD failure. I hit it on my clang-on-x86-64-Ubuntu
setup, and also on FreeBSD. (The latter is just the tests/vm
FreeBSD config, so you can repro that if you need to.)

The ubuntu setup is libglib 2.56.4-0ubuntu0.18.04.4 and
clang 6.0.0-1ubuntu2.

Thanks; I ran:

$ make docker-test-clang@ubuntu1804 DEBUG=1
bash-4.4$ cat > foo.c <<\EOF
> #include <glib.h>
> typedef struct Foo {
>     int i;
> } Foo;
> static void foo_free(Foo *f)
> {
>     g_free(f);
> }
> int main(void) { return 0; }
bash-4.4$ clang -Wall -Werror $(pkg-config --cflags gmodule-2.0) \
  -o foo -c foo.c
3 errors generated.
bash-4.4$ clang -Wall -Werror $(pkg-config --cflags gmodule-2.0) \
  -o foo -c foo.c -Wno-unused-function

to confirm that my test snippet does flush out the error in question. However, removing DEBUG=1 takes a long time to run (hmm, maybe I should set TARGET_LIST to speed it up), and did not reproduce the failure for me without the patch (making it hard to tell if the patch made a difference). I'm still playing with testing, but at least I feel better that this patch is on the right track, now that I have an environment that can reproduce the situation.

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]