qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: Markus Armbruster <armbru@redhat.com>,
	qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: Re: libqemuutil
Date: Tue, 16 Mar 2021 10:24:21 +0100	[thread overview]
Message-ID: <0c90e3ce-6be7-291f-3121-b6d7d725bcdf@redhat.com> (raw)
In-Reply-To: <87zgz38o0v.fsf@dusky.pond.sub.org>

On 16/03/2021 10.07, Markus Armbruster wrote:
> I rebased my "[PATCH v6 00/10] Configurable policy for handling
> deprecated interfaces" to master, and it surprisingly fails to link
> several utility programs.  Here's the first error:
> 
>      gcc  -o tests/bench/benchmark-crypto-hmac tests/bench/benchmark-crypto-hmac.p/benchmark-crypto-hmac.c.o -Wl,--as-needed -Wl,--no-undefined -pie -Wl,--whole-archive libcrypto.fa libauthz.fa libqom.fa -Wl,--no-whole-archive -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -m64 -fstack-protector-strong -Wl,--start-group libqemuutil.a subprojects/libvhost-user/libvhost-user-glib.a subprojects/libvhost-user/libvhost-user.a libcrypto.fa libauthz.fa libqom.fa -pthread -lgthread-2.0 -lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lgnutls -lutil -lm -lgthread-2.0 -lglib-2.0 -lnettle -lgnutls -lpam -Wl,--end-group
>      /usr/bin/ld: libqemuutil.a(util_main-loop.c.o): in function `qemu_set_fd_handler':
>      /work/armbru/qemu/bld-x86/../util/main-loop.c:581: multiple definition of `qemu_set_fd_handler'; libqemuutil.a(stubs_set-fd-handler.c.o):/work/armbru/qemu/bld-x86/../stubs/set-fd-handler.c:8: first defined here
>      collect2: error: ld returned 1 exit status
> 
> Both master and PATCH 01 still link fine, PATCH 02 doesn't.  PATCH 02
> doesn't go anywhere near qemu_set_fd_handler().
> 
> Turns out libqemuutil.a contains two definitions of
> qemu_set_fd_handler().  In master:
> 
>      $ nm --defined-only libqemuutil.a | awk '/:$/ { f=$0 } / qemu_set_fd_handler/ { if (f) { print f; f="" } print $0 }'
>      util_main-loop.c.o:
>      00000000000007fe T qemu_set_fd_handler
>      stubs_set-fd-handler.c.o:
>      0000000000000000 T qemu_set_fd_handler
> 
> This is obviously unhealthy.
> 
> I suspect the linker happens to pick the one that makes things work,
> until something in my patch makes it pick the other one.
> 
> Is qemu_set_fd_handler() the only one?  Nope:
> 
>      $ nm --defined-only bld-x86/libqemuutil.a | awk '/ T / { print $NF }' | sort | uniq -c | grep -v '^ *1 '
>            2 qemu_set_fd_handler
>            2 yank_generic_iochannel
>            2 yank_register_function
>            2 yank_register_instance
>            2 yank_unregister_function
>            2 yank_unregister_instance
> 
> I didn't run into this issue when I posted my series last Friday.  The
> issue now blocks its merge, and today is the soft freeze.  Help!

A very, very quick-n-dirty band-aid is likely to mark the function in stubs 
as weak:

diff --git a/stubs/set-fd-handler.c b/stubs/set-fd-handler.c
--- a/stubs/set-fd-handler.c
+++ b/stubs/set-fd-handler.c
@@ -1,6 +1,7 @@
  #include "qemu/osdep.h"
  #include "qemu/main-loop.h"

+__attribute__((weak))
  void qemu_set_fd_handler(int fd,
                           IOHandler *fd_read,
                           IOHandler *fd_write,

  ... should IMHO be good enough for the soft freeze. In the long run, you 
might want to analyze the problem more thoroughly, of course. I had similar 
problems in the past already, and solved them by moving the stubs around. See:

  b0476d6602adbf818132dc896b585e01f47eaf96
  stubs: Move qemu_timer_notify_cb() and remove
  qemu_notify_event() stub

  8c2787629eee73ca8ce4f100cff4f4946583b4e8
  stubs: Move qemu_fd_register stub to util/main-loop.c

HTH,
  Thomas



  reply	other threads:[~2021-03-16  9:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-16  9:07 libqemuutil Markus Armbruster
2021-03-16  9:24 ` Thomas Huth [this message]
2021-03-16  9:41   ` libqemuutil Paolo Bonzini
2021-03-16  9:28 ` libqemuutil Paolo Bonzini
2021-03-16 10:09   ` libqemuutil Markus Armbruster
2021-03-16 10:15     ` libqemuutil Paolo Bonzini

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=0c90e3ce-6be7-291f-3121-b6d7d725bcdf@redhat.com \
    --to=thuth@redhat.com \
    --cc=armbru@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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.
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).