Hi,

Apparently QEMU static linking is slowly bitroting. Obviously it
depends the libraries an user has installed, anyway it seems there
are not much testing done.

This series fixes few issues, enough to build QEMU on a Ubuntu
aarch64 host, but not yet on a x86_64 host:

    LINK    x86_64-softmmu/qemu-system-x86_64
  /usr/bin/ld: cannot find -lgtk-3
  /usr/bin/ld: cannot find -latk-bridge-2.0
  /usr/bin/ld: cannot find -latspi
  /usr/bin/ld: cannot find -lsystemd
  /usr/bin/ld: cannot find -lgdk-3
  /usr/bin/ld: cannot find -lwayland-egl
  /usr/bin/ld: cannot find -lmirclient
  /usr/bin/ld: cannot find -lmircore
  /usr/bin/ld: cannot find -lmircookie
  /usr/bin/ld: cannot find -lepoxy
  /usr/bin/ld: cannot find -latk-1.0
  /usr/bin/ld: cannot find -lgdk_pixbuf-2.0
  /usr/bin/ld: cannot find -lselinux
  /usr/bin/ld: cannot find -lgtk-3
  /usr/bin/ld: cannot find -latk-bridge-2.0
  /usr/bin/ld: cannot find -latspi
  /usr/bin/ld: cannot find -lsystemd
  /usr/bin/ld: cannot find -lgdk-3
  /usr/bin/ld: cannot find -lwayland-egl
  /usr/bin/ld: cannot find -lmirclient
  /usr/bin/ld: cannot find -lmircore
  /usr/bin/ld: cannot find -lmircookie
  /usr/bin/ld: cannot find -lepoxy
  /usr/bin/ld: cannot find -latk-1.0
  /usr/bin/ld: cannot find -lgdk_pixbuf-2.0
  /usr/bin/ld: cannot find -lselinux
  /usr/bin/ld: attempted static link of dynamic object `/usr/lib/x86_64-linux-gnu/libz.so'
  collect2: error: ld returned 1 exit status

Regards,

Phil.

Philippe Mathieu-Daudé (6):
  configure: Only generate GLUSTERFS variables if glusterfs is usable
  configure: Link test before auto-enabling glusterfs libraries
  configure: Link test before auto-enabling the libusb library
  configure: Link test before auto-enabling the libusbredir library
  configure: Link test before auto-enabling the pulseaudio library
  .travis.yml: Test static linking

 .travis.yml |   5 +++
 configure   | 113 +++++++++++++++++++++++++++++++++++++++-------------
 2 files changed, 90 insertions(+), 28 deletions(-)

-- 
2.20.1

On 6/14/19 9:24 AM, Philippe Mathieu-Daudé wrote:
> Hi,
> 
> Apparently QEMU static linking is slowly bitroting. Obviously it
> depends the libraries an user has installed, anyway it seems there
> are not much testing done.
> 
> This series fixes few issues, enough to build QEMU on a Ubuntu
> aarch64 host, but not yet on a x86_64 host:
> 
>     LINK    x86_64-softmmu/qemu-system-x86_64
>   /usr/bin/ld: cannot find -lgtk-3
>   /usr/bin/ld: cannot find -latk-bridge-2.0
>   /usr/bin/ld: cannot find -latspi
>   /usr/bin/ld: cannot find -lsystemd
>   /usr/bin/ld: cannot find -lgdk-3
>   /usr/bin/ld: cannot find -lwayland-egl
>   /usr/bin/ld: cannot find -lmirclient
>   /usr/bin/ld: cannot find -lmircore
>   /usr/bin/ld: cannot find -lmircookie
>   /usr/bin/ld: cannot find -lepoxy
>   /usr/bin/ld: cannot find -latk-1.0
>   /usr/bin/ld: cannot find -lgdk_pixbuf-2.0
>   /usr/bin/ld: cannot find -lselinux
>   /usr/bin/ld: cannot find -lgtk-3
>   /usr/bin/ld: cannot find -latk-bridge-2.0
>   /usr/bin/ld: cannot find -latspi
>   /usr/bin/ld: cannot find -lsystemd
>   /usr/bin/ld: cannot find -lgdk-3
>   /usr/bin/ld: cannot find -lwayland-egl
>   /usr/bin/ld: cannot find -lmirclient
>   /usr/bin/ld: cannot find -lmircore
>   /usr/bin/ld: cannot find -lmircookie
>   /usr/bin/ld: cannot find -lepoxy
>   /usr/bin/ld: cannot find -latk-1.0
>   /usr/bin/ld: cannot find -lgdk_pixbuf-2.0
>   /usr/bin/ld: cannot find -lselinux
>   /usr/bin/ld: attempted static link of dynamic object `/usr/lib/x86_64-linux-gnu/libz.so'
>   collect2: error: ld returned 1 exit status

This one is funny, when installing libvte on Ubuntu 18.04:

    LINK    x86_64-softmmu/qemu-system-x86_64
  c++: error: /usr/lib/x86_64-linux-gnu/libunistring.so: No such file or
directory
  c++: error: /usr/lib/x86_64-linux-gnu/libunistring.so: No such file or
directory
  c++: error: /usr/lib/x86_64-linux-gnu/libunistring.so: No such file or
directory
  c++: error: /usr/lib/x86_64-linux-gnu/libunistring.so: No such file or
directory

$ pkg-config --libs --static vte-2.91
-lvte-2.91 -lgtk-3 -latk-bridge-2.0 -latspi -ldbus-1 -lpthread -lsystemd
-lgdk-3 -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage
-lXfixes -lxkbcommon -lwayland-cursor -lwayland-egl -lwayland-client
-lepoxy -ldl -lpangocairo-1.0 -lpangoft2-1.0 -lharfbuzz -lm -lgraphite2
-lpango-1.0 -lm -latk-1.0 -lcairo-gobject -lcairo -lz -lpixman-1
-lfontconfig -lexpat -lfreetype -lexpat -lfreetype -lpng16 -lm -lz -lm
-lxcb-shm -lxcb-render -lXrender -lXext -lX11 -lpthread -lxcb -lXau
-lXdmcp -lgdk_pixbuf-2.0 -lm -lpng16 -lm -lz -lm -lgio-2.0 -lz -lresolv
-lselinux -lmount -lgmodule-2.0 -pthread -ldl -lgobject-2.0 -lffi
-lglib-2.0 -pthread -lpcre -pthread -lgnutls -lgmp
/usr/lib/x86_64-linux-gnu/libunistring.so -lidn2 -lhogweed -lgmp
-lnettle -ltasn1 -lp11-kit -lz

$ ls -ld /usr/lib/x86_64-linux-gnu/libunistring.so
ls: cannot access '/usr/lib/x86_64-linux-gnu/libunistring.so': No such
file or directory

$ ls -ld /usr/lib/x86_64-linux-gnu/libunistring.so*
lrwxrwxrwx. 1 root root      21 Mar  3  2018
/usr/lib/x86_64-linux-gnu/libunistring.so.2 -> libunistring.so.2.1.0
-rw-r--r--. 1 root root 1562664 Mar  3  2018
/usr/lib/x86_64-linux-gnu/libunistring.so.2.1.0

The fix is probably "sudo ln -s libunistring.so.2
/usr/lib/x86_64-linux-gnu/libunistring.so".

On Fri, 14 Jun 2019 at 08:27, Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
> Apparently QEMU static linking is slowly bitroting. Obviously it
> depends the libraries an user has installed, anyway it seems there
> are not much testing done.

The main reason for supporting static linking is so we can build
the user-mode emulators. Almost always the problems with
static linking the softmmu binaries and the tools are
issues with the distro's packaging of the static libraries
(pkg-config files which specify things that don't work for
static is a common one).

So we could put in a lot of checking of "is what pkg-config
tells us broken". Or we could just say "we don't support static
linking for anything except the usermode binaries". We
should probably phase in deprecation of that because it's
possible somebody's using it seriously, but it seems like
a fairly weird thing to do to me.

thanks
-- PMM

Peter Maydell <peter.maydell@linaro.org> writes:

> On Fri, 14 Jun 2019 at 08:27, Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
>> Apparently QEMU static linking is slowly bitroting. Obviously it
>> depends the libraries an user has installed, anyway it seems there
>> are not much testing done.
>
> The main reason for supporting static linking is so we can build
> the user-mode emulators. Almost always the problems with
> static linking the softmmu binaries and the tools are
> issues with the distro's packaging of the static libraries
> (pkg-config files which specify things that don't work for
> static is a common one).
>
> So we could put in a lot of checking of "is what pkg-config
> tells us broken". Or we could just say "we don't support static
> linking for anything except the usermode binaries". We
> should probably phase in deprecation of that because it's
> possible somebody's using it seriously, but it seems like
> a fairly weird thing to do to me.

It would be nice to have a --static-user config flag and deprecate the
--static flag. I don't think there is a decent use case for system
emulation targets.

The Gentoo ebuild currently jumps through hoops to build QEMU by doing
the build twice, first for softmmu targets and then for user targets. I
suspect all of that is mostly to handle the reasonable "static-user" use
case which is what people really want*.

*I'm guessing

--
Alex Bennée

On Fri, 14 Jun 2019 at 14:58, Alex Bennée <alex.bennee@linaro.org> wrote:

> It would be nice to have a --static-user config flag and deprecate the
> --static flag. I don't think there is a decent use case for system
> emulation targets.

It would be really tricky to build half with static and half
without: our configure and build system really assumes that
fundamental stuff like "what libraries" and "what compiler flags"
are the same across the whole of the build.

Is --static-user really much better than:
 * allow --static --disable-system --disable-tools
 * forbid --static without --disable-system --disable-tools
 * require users to build the static usermode binaries separately
   from the system/tools build

(which is in practice what we have now) ?

Debian wants both static usermode and non-static usermode
binaries, so they'd still need to build multiple times anyway.

thanks
-- PMM

On 6/14/19 4:30 PM, Peter Maydell wrote:
> On Fri, 14 Jun 2019 at 14:58, Alex Bennée <alex.bennee@linaro.org> wrote:
> 
>> It would be nice to have a --static-user config flag and deprecate the
>> --static flag. I don't think there is a decent use case for system
>> emulation targets.
> 
> It would be really tricky to build half with static and half
> without: our configure and build system really assumes that
> fundamental stuff like "what libraries" and "what compiler flags"
> are the same across the whole of the build.
> 
> Is --static-user really much better than:
>  * allow --static --disable-system --disable-tools
>  * forbid --static without --disable-system --disable-tools
>  * require users to build the static usermode binaries separately
>    from the system/tools build
> 
> (which is in practice what we have now) ?
> 
> Debian wants both static usermode and non-static usermode
> binaries, so they'd still need to build multiple times anyway.

Glad to read, so the v2 of this series is worthful.