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

[Peter Maydell]

On Fri, 2 Oct 2020 at 13:02, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> 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".

My configure command line used to work and now it doesn't.
There is no workaround that I'm aware of that I can use
by tweaking the configure options. That's a clear regression.

> Here are three alternatives to the patch:
>
> - the workaround: just leave things as they are and add
> --disable-libudev to your script.

There is no --disable-udev ! If there was I'd just have
used it.

e104462:bionic:static-sys$  '../../configure'
'--target-list=arm-softmmu' '--enable-debug' '--static'
'--disable-tools' '--disable-sdl' '--disable-gtk' '--disable-vnc'
'--disable-virtfs' '--disable-attr' '--disable-libiscsi'
'--disable-libnfs' '--disable-libusb' '--disable-opengl'
'--disable-numa' '--disable-usb-redir' '--disable-bzip2'
'--audio-drv-list=' '--disable-guest-agent' '--disable-vte'
--disable-udev
ERROR: unknown option --disable-udev
Try '../../configure --help' for more information

> 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 last time this came up it was in an all-in-configure
test, so I took the approach of making the test a bit smarter
to sanity check that what it was getting from pkg-config
really worked:
https://patchew.org/QEMU/20200928160402.7961-1-peter.maydell@linaro.org/
I don't know enough meson to do that in meson, so this patch is
the simple change that fixes the regression by reinstating the
logic configure had.

> - 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 don't think we want to try to say "look at what statically
linked libraries are in Debian". The point of configure
style logic is to look at what is present when we try to compile
and, when something is an optional feature, only compile it
in if it's going to work.

It would be better to do the "see if a static library is present"
test. This isn't too hard to do in configure (compare that
six line fix to the detection of libgio). Hopefully it is
not too hard to do in meson ?

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

I agree that we don't really very solidly support this use case,
and it's pretty much "if it doesn't work we accept point-fixes
to the build machinery and/or recommend more use of --disable-foo".
But it is still useful sometimes to have.

thanks
-- PMM