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
18.04 host.

Peter commented on v1:

  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.

I share his view on this (restricting static linking to qemu-user)
but since the work was already done when I read his comment, I still
send the v2.

Since v1:
- pkg-config already use the '--static' argument, do not add it twice
- Fixed x86_64 host builds (was missing GTK and OpenGL patches)
- Added Niels R-b tag on the first patch
- The Travis-CI job now succeeds:
  https://travis-ci.org/philmd/qemu/jobs/545653697 (6 min 7 sec)

Regards,

Phil.

Philippe Mathieu-Daudé (9):
  configure: Only generate GLUSTERFS variables if glusterfs is usable
  configure: Link test before auto-enabling GlusterFS libraries
  configure: Link test before auto-enabling libusb library
  configure: Link test before auto-enabling libusbredir library
  configure: Link test before auto-enabling PulseAudio library
  configure: Link test before auto-enabling OpenGL libraries
  configure: Link test before auto-enabling GTK libraries
  tests/docker: Kludge for missing libunistring.so symlink on Ubuntu
    18.04
  .travis.yml: Test softmmu static linking

 .travis.yml                                |   5 +
 configure                                  | 121 ++++++++++++++++-----
 tests/docker/dockerfiles/ubuntu1804.docker |   4 +
 3 files changed, 100 insertions(+), 30 deletions(-)

-- 
2.20.1

On 6/14/19 12:07 PM, 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
> 18.04 host.
> 
> Peter commented on v1:
> 
>   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.
> 
> I share his view on this (restricting static linking to qemu-user)
> but since the work was already done when I read his comment, I still
> send the v2.

Alex, any comment?

Patch #1 could go via trivial@, the other should be made obsolete by the
Paolo's switch to Meson.

> Since v1:
> - pkg-config already use the '--static' argument, do not add it twice
> - Fixed x86_64 host builds (was missing GTK and OpenGL patches)
> - Added Niels R-b tag on the first patch
> - The Travis-CI job now succeeds:
>   https://travis-ci.org/philmd/qemu/jobs/545653697 (6 min 7 sec)
> 
> Regards,
> 
> Phil.
> 
> Philippe Mathieu-Daudé (9):
>   configure: Only generate GLUSTERFS variables if glusterfs is usable
>   configure: Link test before auto-enabling GlusterFS libraries
>   configure: Link test before auto-enabling libusb library
>   configure: Link test before auto-enabling libusbredir library
>   configure: Link test before auto-enabling PulseAudio library
>   configure: Link test before auto-enabling OpenGL libraries
>   configure: Link test before auto-enabling GTK libraries
>   tests/docker: Kludge for missing libunistring.so symlink on Ubuntu
>     18.04
>   .travis.yml: Test softmmu static linking
> 
>  .travis.yml                                |   5 +
>  configure                                  | 121 ++++++++++++++++-----
>  tests/docker/dockerfiles/ubuntu1804.docker |   4 +
>  3 files changed, 100 insertions(+), 30 deletions(-)
> 

On Fri, Jun 14, 2019 at 12:07:09PM +0200, 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.

Bitrotting implies that it actually worked in the first place.

AFAIK, configure has never been capable of auto-enabling the
correct set of libraries for static linking, if you have the
equiv dyn libraries present.

I always assumed that anyone who is static loinking QEMU is
passing a big long list of --disable-XXXX args to turn off
all the 3rd party libs for which they don't have a static
build present.

> This series fixes few issues, enough to build QEMU on a Ubuntu
> 18.04 host.
> 
> Peter commented on v1:
> 
>   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.
> 
> I share his view on this (restricting static linking to qemu-user)
> but since the work was already done when I read his comment, I still
> send the v2.

I share Peter's view that we ought to restrict static linking to be
allowed exclusively for user-mode-only builds of QEMU. This is a use
case with a compelling reason to need static builds. It is not bitrotting
as the main distros all do a static user-mode only QEMU build, alongside
the main everything, fully dynamic build.

Static builds of system emulators & other tools get essentially no
testing by developers, distros, or our CI systems. If they do work
it is largely by luck, and likely requires the user to pass many
--disable-XXX flags. While your patches do make configure a bit
nicer in this respect, if we're going to deprecate static builds
of non-user-mode parts, then making static builds easier feels
undesirable.

Lets just get a deprecation warning in right now for this imminent
release.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

On 7/1/19 4:36 PM, Daniel P. Berrangé wrote:
> On Fri, Jun 14, 2019 at 12:07:09PM +0200, 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.
> 
> Bitrotting implies that it actually worked in the first place.
> 
> AFAIK, configure has never been capable of auto-enabling the
> correct set of libraries for static linking, if you have the
> equiv dyn libraries present.
> 
> I always assumed that anyone who is static loinking QEMU is
> passing a big long list of --disable-XXXX args to turn off
> all the 3rd party libs for which they don't have a static
> build present.
> 
>> This series fixes few issues, enough to build QEMU on a Ubuntu
>> 18.04 host.
>>
>> Peter commented on v1:
>>
>>   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.
>>
>> I share his view on this (restricting static linking to qemu-user)
>> but since the work was already done when I read his comment, I still
>> send the v2.
> 
> I share Peter's view that we ought to restrict static linking to be
> allowed exclusively for user-mode-only builds of QEMU. This is a use
> case with a compelling reason to need static builds. It is not bitrotting
> as the main distros all do a static user-mode only QEMU build, alongside
> the main everything, fully dynamic build.
> 
> Static builds of system emulators & other tools get essentially no
> testing by developers, distros, or our CI systems. If they do work
> it is largely by luck, and likely requires the user to pass many
> --disable-XXX flags. While your patches do make configure a bit
> nicer in this respect, if we're going to deprecate static builds
> of non-user-mode parts, then making static builds easier feels
> undesirable.

OK, I agree then.

> 
> Lets just get a deprecation warning in right now for this imminent
> release.
> 
> Regards,
> Daniel
>