[Qemu-devel] [PATCH RFC] Makefile.target: prepend $libs_softmmu to $LIBS

[Qemu-devel] [PATCH RFC] Makefile.target: prepend $libs_softmmu to $LIBS

[Wei Liu]

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(-)

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
-- 
1.9.1

Re: [Qemu-devel] [PATCH RFC] Makefile.target: prepend $libs_softmmu to $LIBS

[Peter Maydell]

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

Re: [Qemu-devel] [PATCH RFC] Makefile.target: prepend $libs_softmmu to $LIBS

[Wei Liu]

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

Re: [Qemu-devel] [PATCH RFC] Makefile.target: prepend $libs_softmmu to $LIBS

[Stefano Stabellini]

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.

Re: [Qemu-devel] [PATCH RFC] Makefile.target: prepend $libs_softmmu to $LIBS

[Peter Maydell]

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

Re: [Qemu-devel] [PATCH RFC] Makefile.target: prepend $libs_softmmu to $LIBS

[Wei Liu]

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

Re: [Qemu-devel] [PATCH RFC] Makefile.target: prepend $libs_softmmu to $LIBS

[Paolo Bonzini]

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
> 

Re: [Qemu-devel] [PATCH RFC] Makefile.target: prepend $libs_softmmu to $LIBS

[Paolo Bonzini]

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.
> 
> 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)

A side effect of the patch is that changes to libs_softmmu do not
propagate into LIBS.  So you also need this:

diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
index 7ed76a9..4eb9e98 100644
--- a/hw/display/Makefile.objs
+++ b/hw/display/Makefile.objs
@@ -20,7 +20,7 @@ common-obj-$(CONFIG_ZAURUS) += tc6393xb.o
 
 ifeq ($(CONFIG_MILKYMIST_TMU2),y)
 common-obj-y += milkymist-tmu2.o
-libs_softmmu += $(GLX_LIBS)
+milkymist-tmu2.o-libs += $(GLX_LIBS)
 endif
 
 obj-$(CONFIG_OMAP) += omap_dss.o


Because there are pending changes to OpenGL detection, I'll keep
this patch queued in my tree and will probably submit it only for
2.4.

Paolo

Re: [Qemu-devel] [PATCH RFC] Makefile.target: prepend $libs_softmmu to $LIBS

[Wei Liu]

On Tue, Mar 10, 2015 at 11:16:40AM +0100, Paolo Bonzini wrote:
> 
> 
> 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.
> > 
> > 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)
> 
> A side effect of the patch is that changes to libs_softmmu do not
> propagate into LIBS.  So you also need this:
> 
> diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
> index 7ed76a9..4eb9e98 100644
> --- a/hw/display/Makefile.objs
> +++ b/hw/display/Makefile.objs
> @@ -20,7 +20,7 @@ common-obj-$(CONFIG_ZAURUS) += tc6393xb.o
>  
>  ifeq ($(CONFIG_MILKYMIST_TMU2),y)
>  common-obj-y += milkymist-tmu2.o
> -libs_softmmu += $(GLX_LIBS)
> +milkymist-tmu2.o-libs += $(GLX_LIBS)
>  endif
>  
>  obj-$(CONFIG_OMAP) += omap_dss.o
> 
> 
> Because there are pending changes to OpenGL detection, I'll keep
> this patch queued in my tree and will probably submit it only for
> 2.4.

I don't quite follow. Do you want me to carry your patch in my own tree,
wait for you to submit your patch (and get merged), then I submit my
patch again?

Wei.

> 
> Paolo

Re: [Qemu-devel] [PATCH RFC] Makefile.target: prepend $libs_softmmu to $LIBS

[Paolo Bonzini]

On 10/03/2015 12:57, Wei Liu wrote:
> > Because there are pending changes to OpenGL detection, I'll keep
> > this patch queued in my tree and will probably submit it only for
> > 2.4.
>
> I don't quite follow. Do you want me to carry your patch in my own tree,
> wait for you to submit your patch (and get merged), then I submit my
> patch again?

I'll submit a pull request for your patch, but it will likely have to
wait for QEMU 2.4.

Paolo

Re: [Qemu-devel] [PATCH RFC] Makefile.target: prepend $libs_softmmu to $LIBS

[Wei Liu]

On Tue, Mar 10, 2015 at 01:00:15PM +0100, Paolo Bonzini wrote:
> 
> 
> On 10/03/2015 12:57, Wei Liu wrote:
> > > Because there are pending changes to OpenGL detection, I'll keep
> > > this patch queued in my tree and will probably submit it only for
> > > 2.4.
> >
> > I don't quite follow. Do you want me to carry your patch in my own tree,
> > wait for you to submit your patch (and get merged), then I submit my
> > patch again?
> 
> I'll submit a pull request for your patch, but it will likely have to
> wait for QEMU 2.4.
> 

That's fine by me. It's not urgent.

Wei.

> Paolo