17.08.2023 02:23, Athos Ribeiro wrote:
..
I am not really sure what exactly the user is trying to accomplish with
their builds. However, supporting his case seems to be covered by the
debian policy in
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-static
and the static library is 260Kb (which, on a second thought, is actually
quite large if we consider the current size of the -dev package).
Yes, I know the policy. I try to provide static libs for library packages
I maintain, for which it makes sense, despite the policy. When I packaged
libslirp (and ditto for a few other libs, eg spice), it had.. issues with
wrong extra deps, - when pkgconfig listed Libs.private which weren't listed
in the final dependencies because these packages aren't actually used, but
only needed with static linking. So I had to either maintain the Depends
field manually (and keep it up to date), or to strip Libs.private entirely
and be done with that. Sometimes I decide for the latter.
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.
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).
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.
Still, the current HEAD of the master branch in salsa FTBFS. It seems
the offending commit is
https://salsa.debian.org/qemu-team/libslirp/-/commit/fc4544bb780d861ad982b9a4184cf3741fc51af4
The relevant bit in the failure is
../meson.build:1:0: ERROR: Unknown options: "disable_tests"
It definitely worked at the time. Perhaps some things changed since that.
removing that option makes the builds pass again:
diff --git a/debian/rules b/debian/rules
index 85618b8..96cbd3c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,4 +4,4 @@ build-arch build-indep build clean install-indep install-arch
install binary-arc
dh $@ --buildsystem=meson+ninja
override_dh_auto_configure:
- dh_auto_configure -- --default-library=both -Ddisable_tests=$(if
$(filter nocheck,${DEB_BUILD_OPTIONS}),true,false)
+ dh_auto_configure -- --default-library=both
The bug (#981893) was there for a reason, I think, so at the very
least this should be accomplished with Reopen: #981893.
/mjt
