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 <address@hidden> 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.