| Message ID | 1398070878-693120-1-git-send-email-mjt@msgid.tls.msk.ru |
|---|---|
| State | New |
| Headers | show |
21.04.2014 13:01, Michael Tokarev wrote: > libtool has an argument for .syms file, which is -export-symbols. > There's no argument `-export-syms', and it looks like at least on > linux, -export-syms is just ignored. Use the correct argument, > -export-symbols, to actually get the right export list. Note: with this patch applied, linking vscclient fails due to the following symbols missing: qemu_mutex_lock qemu_mutex_unlock qemu_cond_wait qemu_cond_signal qemu_thread_create socket_init qemu_socket qemu_mutex_init qemu_cond_init So it looks like a preparation patch is needed before this one, to ensure bisectability. Should those symbols be exported by libcacard (hence listed in the .syms file), or should vscclient link line use more objects? Thanks, /mjt > Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> > --- > libcacard/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libcacard/Makefile b/libcacard/Makefile > index 6b06448..ca08991 100644 > --- a/libcacard/Makefile > +++ b/libcacard/Makefile > @@ -24,7 +24,7 @@ vscclient$(EXESUF): libcacard/vscclient.o libcacard.la > # Rules for building libcacard standalone library > > libcacard.la: LDFLAGS += -rpath $(libdir) -no-undefined \ > - -export-syms $(SRC_PATH)/libcacard/libcacard.syms > + -export-symbols $(SRC_PATH)/libcacard/libcacard.syms > libcacard.la: LIBS = $(libcacard_libs) > libcacard.la: $(libcacard-lobj-y) > $(call LINK,$^) >
On 04/21/2014 12:09 PM, Michael Tokarev wrote: > 21.04.2014 13:01, Michael Tokarev wrote: >> libtool has an argument for .syms file, which is -export-symbols. >> There's no argument `-export-syms', and it looks like at least on >> linux, -export-syms is just ignored. Use the correct argument, >> -export-symbols, to actually get the right export list. > > Note: with this patch applied, linking vscclient fails due to the > following symbols missing: > > qemu_mutex_lock > qemu_mutex_unlock > qemu_cond_wait > qemu_cond_signal > qemu_thread_create > socket_init > qemu_socket > qemu_mutex_init > qemu_cond_init > > So it looks like a preparation patch is needed before this one, to > ensure bisectability. > > Should those symbols be exported by libcacard (hence listed in the > .syms file), or should vscclient link line use more objects? They should not be exported by libcacard. I'm not sure what is happening here except to note that the list of objects being linked must satisfy all missing symbols since it results in a loadable and executable executable. > > Thanks, > > /mjt > >> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> >> --- >> libcacard/Makefile | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libcacard/Makefile b/libcacard/Makefile >> index 6b06448..ca08991 100644 >> --- a/libcacard/Makefile >> +++ b/libcacard/Makefile >> @@ -24,7 +24,7 @@ vscclient$(EXESUF): libcacard/vscclient.o libcacard.la >> # Rules for building libcacard standalone library >> >> libcacard.la: LDFLAGS += -rpath $(libdir) -no-undefined \ >> - -export-syms $(SRC_PATH)/libcacard/libcacard.syms >> + -export-symbols $(SRC_PATH)/libcacard/libcacard.syms >> libcacard.la: LIBS = $(libcacard_libs) >> libcacard.la: $(libcacard-lobj-y) >> $(call LINK,$^) >> >
27.04.2014 12:05, Alon Levy wrote: > On 04/21/2014 12:09 PM, Michael Tokarev wrote: >> 21.04.2014 13:01, Michael Tokarev wrote: >>> libtool has an argument for .syms file, which is -export-symbols. >>> There's no argument `-export-syms', and it looks like at least on >>> linux, -export-syms is just ignored. Use the correct argument, >>> -export-symbols, to actually get the right export list. >> >> Note: with this patch applied, linking vscclient fails due to the >> following symbols missing: >> >> qemu_mutex_lock >> qemu_mutex_unlock >> qemu_cond_wait >> qemu_cond_signal >> qemu_thread_create >> socket_init >> qemu_socket >> qemu_mutex_init >> qemu_cond_init >> >> So it looks like a preparation patch is needed before this one, to >> ensure bisectability. >> >> Should those symbols be exported by libcacard (hence listed in the >> .syms file), or should vscclient link line use more objects? > > They should not be exported by libcacard. I'm not sure what is happening > here except to note that the list of objects being linked must satisfy > all missing symbols since it results in a loadable and executable > executable. Well. vscclient explicitly uses them in the code, but only links with libcacard, not with other qemu objects. So adding proper qemu objects here should be fine. I can take care of that. On the other hand, some of those are mutexes, shouldn't the same objects be used inside the library and inside the executable? I don't know. Thanks, /mjt
Il 27/04/2014 10:10, Michael Tokarev ha scritto: >>> >> qemu_mutex_lock >>> >> qemu_mutex_unlock >>> >> qemu_cond_wait >>> >> qemu_cond_signal >>> >> qemu_thread_create >>> >> socket_init >>> >> qemu_socket >>> >> qemu_mutex_init >>> >> qemu_cond_init >>> >> >>> >> So it looks like a preparation patch is needed before this one, to >>> >> ensure bisectability. >>> >> >>> >> Should those symbols be exported by libcacard (hence listed in the >>> >> .syms file), or should vscclient link line use more objects? >> > >> > They should not be exported by libcacard. I'm not sure what is happening >> > here except to note that the list of objects being linked must satisfy >> > all missing symbols since it results in a loadable and executable >> > executable. > Well. vscclient explicitly uses them in the code, but only links with > libcacard, not with other qemu objects. So adding proper qemu objects > here should be fine. I can take care of that. > > On the other hand, some of those are mutexes, shouldn't the same objects > be used inside the library and inside the executable? I don't know. vscclient should link to libqemuutil.a. Paolo
27.04.2014 13:54, Paolo Bonzini wrote: > Il 27/04/2014 10:10, Michael Tokarev ha scritto: [] >> Well. vscclient explicitly uses them in the code, but only links with >> libcacard, not with other qemu objects. So adding proper qemu objects >> here should be fine. I can take care of that. >> >> On the other hand, some of those are mutexes, shouldn't the same objects >> be used inside the library and inside the executable? I don't know. > > vscclient should link to libqemuutil.a. It doesn't work either. Adding libqemuutil.a to the link like produces this: libqemuutil.a(osdep.o): In function `qemu_open': /build/kvm/git/util/osdep.c:171: undefined reference to `monitor_fdset_get_fd' /build/kvm/git/util/osdep.c:181: undefined reference to `monitor_fdset_dup_fd_add' libqemuutil.a(osdep.o): In function `qemu_close': /build/kvm/git/util/osdep.c:224: undefined reference to `monitor_fdset_dup_fd_find' /build/kvm/git/util/osdep.c:230: undefined reference to `monitor_fdset_dup_fd_remove' libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_alloc': /build/kvm/git/util/oslib-posix.c:141: undefined reference to `trace_qemu_anon_ram_alloc' libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_free': /build/kvm/git/util/oslib-posix.c:153: undefined reference to `trace_qemu_anon_ram_free' libqemuutil.a(qemu-error.o): In function `error_vprintf': /build/kvm/git/util/qemu-error.c:23: undefined reference to `cur_mon' /build/kvm/git/util/qemu-error.c:24: undefined reference to `cur_mon' /build/kvm/git/util/qemu-error.c:24: undefined reference to `monitor_vprintf' libqemuutil.a(qemu-error.o): In function `error_printf_unless_qmp': /build/kvm/git/util/qemu-error.c:47: undefined reference to `monitor_cur_is_qmp' libqemuutil.a(qemu-error.o): In function `error_print_loc': /build/kvm/git/util/qemu-error.c:174: undefined reference to `cur_mon' collect2: error: ld returned 1 exit status On the other hand, all those symbols are used (and defined) in libcacard.so (but not exported). It looks like we need some more clean separation of the API... /mjt
----- Messaggio originale ----- > Da: "Michael Tokarev" <mjt@tls.msk.ru> > A: "Paolo Bonzini" <pbonzini@redhat.com>, "Alon Levy" <alevy@redhat.com> > Cc: qemu-devel@nongnu.org > Inviato: Domenica, 27 aprile 2014 14:59:45 > Oggetto: Re: [Qemu-devel] [PATCH] libcacard: actually use the symbols file > > 27.04.2014 13:54, Paolo Bonzini wrote: > > Il 27/04/2014 10:10, Michael Tokarev ha scritto: > [] > >> Well. vscclient explicitly uses them in the code, but only links with > >> libcacard, not with other qemu objects. So adding proper qemu objects > >> here should be fine. I can take care of that. > >> > >> On the other hand, some of those are mutexes, shouldn't the same objects > >> be used inside the library and inside the executable? I don't know. > > > > vscclient should link to libqemuutil.a. ... and libqemustub.a (I thought it already did that). Paolo
27.04.2014 17:35, Paolo Bonzini пишет: > > > ----- Messaggio originale ----- >> Da: "Michael Tokarev" <mjt@tls.msk.ru> >> A: "Paolo Bonzini" <pbonzini@redhat.com>, "Alon Levy" <alevy@redhat.com> >> Cc: qemu-devel@nongnu.org >> Inviato: Domenica, 27 aprile 2014 14:59:45 >> Oggetto: Re: [Qemu-devel] [PATCH] libcacard: actually use the symbols file >> >> 27.04.2014 13:54, Paolo Bonzini wrote: >>> Il 27/04/2014 10:10, Michael Tokarev ha scritto: >> [] >>>> Well. vscclient explicitly uses them in the code, but only links with >>>> libcacard, not with other qemu objects. So adding proper qemu objects >>>> here should be fine. I can take care of that. >>>> >>>> On the other hand, some of those are mutexes, shouldn't the same objects >>>> be used inside the library and inside the executable? I don't know. >>> >>> vscclient should link to libqemuutil.a. > > ... and libqemustub.a (I thought it already did that). Aha. That one works. (Nope, vscclient only linked with libcacard.la previously, just its main object and libcacard.la). So now, with proper symbols exported by libcacard.so, and adding libqemuutil.a and libqemustub.a, that's what I'm getting on x86_64: text data bss dec hex filename 17797 1440 560 19797 4d55 vscclient-orig-libcacard-only 47814 2072 4776 54662 d586 vscclient-libcacard+qemuutil+stubs That's more than 2x the size difference!.. ;) (stripped) Most stuff being added from libqemuutul.a and libqemustub.a is already linked to libcacard.so, but with proper symbol exporting it remains private. Oh well. So, what do we do here? Should we actually enable proper exporting? /mjt
Il 27/04/2014 15:53, Michael Tokarev ha scritto:
> So, what do we do here? Should we actually enable proper exporting?
Yes, definitely. If you don't want libqemuutil/libqemustub, you can
rewrite things to use GLib instead of the handful of libqemuutil symbols
that vscclient actually needs.
Paolo
27.04.2014 18:14, Paolo Bonzini wrote: > Il 27/04/2014 15:53, Michael Tokarev ha scritto: >> So, what do we do here? Should we actually enable proper exporting? > > Yes, definitely. If you don't want libqemuutil/libqemustub, you can rewrite things to use GLib instead of the handful of libqemuutil symbols that vscclient actually needs. Actually that's also true for libcacard itself ;) /mjt
diff --git a/libcacard/Makefile b/libcacard/Makefile index 6b06448..ca08991 100644 --- a/libcacard/Makefile +++ b/libcacard/Makefile @@ -24,7 +24,7 @@ vscclient$(EXESUF): libcacard/vscclient.o libcacard.la # Rules for building libcacard standalone library libcacard.la: LDFLAGS += -rpath $(libdir) -no-undefined \ - -export-syms $(SRC_PATH)/libcacard/libcacard.syms + -export-symbols $(SRC_PATH)/libcacard/libcacard.syms libcacard.la: LIBS = $(libcacard_libs) libcacard.la: $(libcacard-lobj-y) $(call LINK,$^)
libtool has an argument for .syms file, which is -export-symbols. There's no argument `-export-syms', and it looks like at least on linux, -export-syms is just ignored. Use the correct argument, -export-symbols, to actually get the right export list. Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> --- libcacard/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)