[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libqemuutil
From: |
Thomas Huth |
Subject: |
Re: libqemuutil |
Date: |
Tue, 16 Mar 2021 10:24:21 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 |
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