Re: [PATCH] meson.build: Don't look for libudev for static builds

[Paolo Bonzini]

On 02/10/20 12:52, Peter Maydell wrote:
> commit f01496a314d916 moved the logic for detecting libudev from
> configure to meson.build, but in the process it dropped the condition
> that meant we only ask pkg-config about libudev for a non-static
> build.
> 
> This breaks static builds of the system emulators on at least Ubuntu
> 18.04.4, because on that host there is no static libudev but
> pkg-config still claims it exists.
> 
> Reinstate the logic that we had in the configure check.
> 
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

I don't think this is a good idea.  Having a completely new build system
also lets us notice all these weird one-off tests, decide whether they
are worth being kept (like the SDL -Wno-undef workaround) or not, and
possibly come up with a policy that avoids having to make one-off decisions.

If "../configure --static" worked and now doesn't then it would be a
clear regression, but a one off check should have a bigger justification
than "39 --disable switches have worked so far and 39 < 40".

Here are three alternatives to the patch:

- the workaround: just leave things as they are and add
--disable-libudev to your script.  We have just added a month ago a
completely new dependency that would have the same issue (libu2f); we
didn't add "test $static" just because you don't have libu2f installed
and therefore you didn't notice.  The day you updated your system ended
up with libu2f-dev installed, you would probably just add
--disable-libu2f instead of adding a test for $static.  So why should
libudev be treated differently?

- the cheap fix: deprecate static building of emulators in the configure
script (in the meanwhile you add --disable-libudev); if people complain,
we figure out the dependencies that they care about and we try to
understand if it's actually possible to build a statically linked
emulator for their usecase.

- the complicated fix: check which statically linked libraries are
available in e.g. Debian and disable _all_ other dependencies with
--static (most of them will be the ones that you already have to disable
 in your script, and most of them will be in configure).  Based on the
outcome, decide whether it's actually possible to build a statically
linked emulator that makes sense.

I wouldn't be surprised if people trying to statically build emulators
are getting worse performance just due to a missing static libaio or
libio_uring, for example, and these people might even be building a
statically-linked QEMU for use with KVM (like Firecracker), i.e. they
would care about performance.

Finally, no matter how we proceed, static building of system emulators
is not covered by either CI or tests/docker (only user-mode emulators
are).  Even if we deprecate it, we should make sure that your
configuration is reproduced in either Travis or GitLab, otherwise people
will keep on breaking it.  That would also document that building a
statically-linked system emulator is messy and requires a few dozen
--disable options.

Thanks,

Paolo

> We could certainly do something cleverer here, but basic "convert
> from configure to meson" should in general not also be changing the
> detection logic IMHO.  We can make the logic smarter as a follow-on
> patch if desired.
> ---
>  meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meson.build b/meson.build
> index 3161c1f037a..07da66e1d81 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -271,7 +271,7 @@ if 'CONFIG_CURL' in config_host
>                              link_args: config_host['CURL_LIBS'].split())
>  endif
>  libudev = not_found
> -if targetos == 'linux' and (have_system or have_tools)
> +if targetos == 'linux' and (have_system or have_tools) and not enable_static
>    libudev = dependency('libudev',
>                         required: get_option('mpath').enabled(),
>                         static: enable_static)
>