| Message ID | 1425912873-21215-1-git-send-email-wei.liu2@citrix.com |
|---|---|
| State | New |
| Headers | show |
On 9 March 2015 at 23:54, Wei Liu <wei.liu2@citrix.com> wrote: > I discovered a problem when trying to build QEMU statically with gcc. > libm is an element of LIBS while libpixman-1 is an element in > libs_softmmu. Libpixman references functions in libm, so the original > ordering makes linking fail. > > This fix is to reorder $libs_softmmu and $LIBS to make -lm appear after > -lpixman-1. However I'm not quite sure if this is the right fix, hence > the RFC tag. > > Normally QEMU is built with c++ compiler which happens to link in libm > (at least this is the case with g++), so building QEMU statically > normally just works and nobody notices this issue. Actually I think nobody notices it because they don't statically link the softmmu executables. Static linking is really intended for the linux-user executables. Maybe we should actively stop configure allowing a static build of the softmmu and tools binaries, rather than having configs which nobody really tests? Or is there a genuine use case for them? thanks -- PMM
On Tue, Mar 10, 2015 at 12:11:44AM +0900, Peter Maydell wrote: > On 9 March 2015 at 23:54, Wei Liu <wei.liu2@citrix.com> wrote: > > I discovered a problem when trying to build QEMU statically with gcc. > > libm is an element of LIBS while libpixman-1 is an element in > > libs_softmmu. Libpixman references functions in libm, so the original > > ordering makes linking fail. > > > > This fix is to reorder $libs_softmmu and $LIBS to make -lm appear after > > -lpixman-1. However I'm not quite sure if this is the right fix, hence > > the RFC tag. > > > > Normally QEMU is built with c++ compiler which happens to link in libm > > (at least this is the case with g++), so building QEMU statically > > normally just works and nobody notices this issue. > > Actually I think nobody notices it because they don't statically > link the softmmu executables. Static linking is really intended > for the linux-user executables. > > Maybe we should actively stop configure allowing a static build > of the softmmu and tools binaries, rather than having configs which > nobody really tests? Or is there a genuine use case for them? > I'm trying to build QEMU as Xen's stubdom. That would certainly require static linking. This is a usecase we care. An we can also test this configuration after we make everything work and put things into our own test system. Wei. > thanks > -- PMM
On Mon, 9 Mar 2015, Wei Liu wrote: > On Tue, Mar 10, 2015 at 12:11:44AM +0900, Peter Maydell wrote: > > On 9 March 2015 at 23:54, Wei Liu <wei.liu2@citrix.com> wrote: > > > I discovered a problem when trying to build QEMU statically with gcc. > > > libm is an element of LIBS while libpixman-1 is an element in > > > libs_softmmu. Libpixman references functions in libm, so the original > > > ordering makes linking fail. > > > > > > This fix is to reorder $libs_softmmu and $LIBS to make -lm appear after > > > -lpixman-1. However I'm not quite sure if this is the right fix, hence > > > the RFC tag. > > > > > > Normally QEMU is built with c++ compiler which happens to link in libm > > > (at least this is the case with g++), so building QEMU statically > > > normally just works and nobody notices this issue. > > > > Actually I think nobody notices it because they don't statically > > link the softmmu executables. Static linking is really intended > > for the linux-user executables. > > > > Maybe we should actively stop configure allowing a static build > > of the softmmu and tools binaries, rather than having configs which > > nobody really tests? Or is there a genuine use case for them? > > > > I'm trying to build QEMU as Xen's stubdom. That would certainly require > static linking. This is a usecase we care. An we can also test this > configuration after we make everything work and put things into our own > test system. Let me further expand on this: stubdom is short for stub-domain. A small tiny domain with just a single executable in it (QEMU) compiled against a unikernel (tipically Mini-OS, it could be a Rumpkernel or OSv in the future) and running in kernel space. People have been using stubdoms for a while now with older versions of QEMU mostly for security and isolation. We are trying to get upstream QEMU to work as a stubdom too.
On 09/03/2015 15:54, Wei Liu wrote: > I discovered a problem when trying to build QEMU statically with gcc. > libm is an element of LIBS while libpixman-1 is an element in > libs_softmmu. Libpixman references functions in libm, so the original > ordering makes linking fail. > > This fix is to reorder $libs_softmmu and $LIBS to make -lm appear after > -lpixman-1. However I'm not quite sure if this is the right fix, hence > the RFC tag. That's a bug in pixman: $ pkg-config --libs --static pixman-1 -lpixman-1 It should have included -lm as well. However, I think I'm okay with this patch. There's nothing fundamentally wrong with it, and running modern QEMU as stubdom is definitely a valuable usecase. Paolo > Normally QEMU is built with c++ compiler which happens to link in libm > (at least this is the case with g++), so building QEMU statically > normally just works and nobody notices this issue. > > Signed-off-by: Wei Liu <wei.liu2@citrix.com> > --- > Makefile.target | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Makefile.target b/Makefile.target > index 2262d89..1083377 100644 > --- a/Makefile.target > +++ b/Makefile.target > @@ -134,7 +134,7 @@ obj-$(CONFIG_KVM) += kvm-all.o > obj-y += memory.o savevm.o cputlb.o > obj-y += memory_mapping.o > obj-y += dump.o > -LIBS+=$(libs_softmmu) > +LIBS := $(libs_softmmu) $(LIBS) > > # xen support > obj-$(CONFIG_XEN) += xen-common.o >
On 10 March 2015 at 00:23, Wei Liu <wei.liu2@citrix.com> wrote: > On Tue, Mar 10, 2015 at 12:11:44AM +0900, Peter Maydell wrote: >> Maybe we should actively stop configure allowing a static build >> of the softmmu and tools binaries, rather than having configs which >> nobody really tests? Or is there a genuine use case for them? > I'm trying to build QEMU as Xen's stubdom. That would certainly require > static linking. This is a usecase we care. An we can also test this > configuration after we make everything work and put things into our own > test system. Does that use a custom libc or something? glibc certainly does not like static linking and warns all over the place about things in functions in glib which we use in the softmmu case. -- PMM
On Tue, Mar 10, 2015 at 01:36:49AM +0900, Peter Maydell wrote: > On 10 March 2015 at 00:23, Wei Liu <wei.liu2@citrix.com> wrote: > > On Tue, Mar 10, 2015 at 12:11:44AM +0900, Peter Maydell wrote: > >> Maybe we should actively stop configure allowing a static build > >> of the softmmu and tools binaries, rather than having configs which > >> nobody really tests? Or is there a genuine use case for them? > > > I'm trying to build QEMU as Xen's stubdom. That would certainly require > > static linking. This is a usecase we care. An we can also test this > > configuration after we make everything work and put things into our own > > test system. > > Does that use a custom libc or something? glibc certainly does > not like static linking and warns all over the place about > things in functions in glib which we use in the softmmu case. > Yes, we build every library including libc. Wei. > -- PMM
diff --git a/Makefile.target b/Makefile.target index 2262d89..1083377 100644 --- a/Makefile.target +++ b/Makefile.target @@ -134,7 +134,7 @@ obj-$(CONFIG_KVM) += kvm-all.o obj-y += memory.o savevm.o cputlb.o obj-y += memory_mapping.o obj-y += dump.o -LIBS+=$(libs_softmmu) +LIBS := $(libs_softmmu) $(LIBS) # xen support obj-$(CONFIG_XEN) += xen-common.o
I discovered a problem when trying to build QEMU statically with gcc. libm is an element of LIBS while libpixman-1 is an element in libs_softmmu. Libpixman references functions in libm, so the original ordering makes linking fail. This fix is to reorder $libs_softmmu and $LIBS to make -lm appear after -lpixman-1. However I'm not quite sure if this is the right fix, hence the RFC tag. Normally QEMU is built with c++ compiler which happens to link in libm (at least this is the case with g++), so building QEMU statically normally just works and nobody notices this issue. Signed-off-by: Wei Liu <wei.liu2@citrix.com> --- Makefile.target | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)