[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
linux-user vs system build options and libraries
From: |
Michael Tokarev |
Subject: |
linux-user vs system build options and libraries |
Date: |
Mon, 11 Sep 2023 10:36:02 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 |
Hi!
I noticed that linux-user binaries, when built separately (with
--enable-linux-user --disable-system) or when built as part of
system build (--enable-linux-user --enable-system) differ in size
and link with significantly more libraries which they shouldn't
link with. libnuma, liburing, libgnutls, - that's what gets linked,
just to name a few. zlib is also there which most likely shouldn't
be.
Looking at the link lines I see a whole lot of various stuff being
linked, thankfully with --as-needed so most of it gets dropped by
the linker - these are stuff like pixman and many other things.
I already mentioned this before, - to me, whole meson.build options
thing is done a bit backwards: we use have_foo to mean NEED_foo, so
in quite a few places these meanings are wrongly intermixed. Like,
if I try a linux-user build with --enable-spice, it will tried to
be used even if it makes no sense whatsoever. We could check spice
and enable have_spice this way (or spice_libs=/spice_defs= etc),
but only use it in those build targets which actually need it.
Also, which might be a separate issue, --enable-plugins seems to
be in effect for linux-user too, which result in libgmodule being
linked with.
Also, there's no way to build/install just the linux-user parts
without, say, installing keymap files, docs are always built,
and so on..
It looks like we've quite barbarian build system still, even after
conversion to meson :)
/mjt
- linux-user vs system build options and libraries,
Michael Tokarev <=