On Thu, Aug 17, 2023 at 10:50:31AM +0300, Michael Tokarev wrote:
17.08.2023 02:23, Athos Ribeiro wrote:
There is also this thread in the qemu-devel mailing list which may be
relevant:
https://lists.gnu.org/archive/html/qemu-devel/2022-08/msg01044.html
I know all these libs can be built in static libfoo.a variant, the build
system allows that. The question is how much time/energy we want to
push there to maintain that stuff, wrt how much sense it makes.
I see.
Despite the size, are there any other downsides on supporting this here
which I am not seeing?
At the very least, it will fail in exactly the same way with other libs
(libspice-server).
It's been this way for quite some years.
For some commonly used libs shipping static variant makes sense. Even for
libglib (which is used by qemu-user-static in static form!) shipping
a static library is questionable, because, well, libglib isn't designed
to be used as a static lib! Notice the qemu-user-static build log: at
the link stage there's a warning about getpwent_r being problematic in
static link, - but qemu linux-user does not use getpwent! - this is because
there's a single file in glib, something-utils.c, which has numerous
"commonly used" functions, with g_gethomedir() (I don't remember the exact
name) among them. qemu linux-user uses something else from that file, and
whole thing gets linked into the binary, including getpwent and other stuff.
This should be split into separate .c files for it to work, right now it
is a big waste (incl. RAM when running qemu-user). But since we need
qemu-user-static, we have to ship static variant of libglib, despite it
being not a thing to begin with (it is just the common build system which
allows building libfoo.a too).
Thanks for the explanation and thorough reply, Michael. I suppose I
will request/wait for more input from the reporter regarding
https://bugs.launchpad.net/debian/+source/libslirp/+bug/2029431/comments/3
https://salsa.debian.org/qemu-team/libslirp/-/merge_requests/2
This MR lacks code which will grab the resulting libslirp.a so build will fail.
It's trivial to build a static library in addition to regular shared. But I
really want to understand the reasoning.
There is an entry in debian/libslirp-dev.install installing the static
library which should be enough, shouldn't it?
Yeah, it is exactly what's missing.
FWIW, it is there:
https://salsa.debian.org/qemu-team/libslirp/-/merge_requests/2/diffs#62c82f62d2982134f9103384374819b97e418bca_4_4
--
Athos Ribeiro
