Dear Maintainer,

The following bug was reported for libslirp in ubuntu:
https://bugs.launchpad.net/ubuntu/+source/libslirp/+bug/2029431

The bug is a request to ship a static library in libslirp-dev.  This
seems to be a fair request, therefore, I have submitted the following MR
in salsa to to provide the static lib in the dev package:

https://salsa.debian.org/qemu-team/libslirp/-/merge_requests/2

Thanks!

16.08.2023 23:33, Athos Ribeiro wrote:

What are you going to build with static slirp?

I'm curious.

This bug report talks about static build of qemu-system.  This is something which
is difficult and definitely not supported upstream, - only very limited set of
options can be enabled for a static qemu-system build.  Myself, I see no value
whatsoever in providing or pretending to provide static build of qemu, and will
not support this in debian.

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.

/mjt

Hi Michael,

Thank you for the quick reply.

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

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

Despite the size, are there any other downsides on supporting this here
which I am not seeing?

There is an entry in debian/libslirp-dev.install installing the static
library which should be enough, shouldn't it?

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"

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

17.08.2023 02:23, Athos Ribeiro wrote:
..

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.

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.

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

Yeah, it is exactly what's missing.

It definitely worked at the time. Perhaps some things changed since that.

The bug (#981893) was there for a reason, I think, so at the very
least this should be accomplished with Reopen: #981893.

/mjt

I see.

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/diffs#62c82f62d2982134f9103384374819b97e418bca_4_4

Dear Athos and Michael,

		 Virtual Distributed Ethernet (VDE) is a set of tools that provide an
effective communication platform for virtual entities interoperability. [1][2]

The VDE project tools are available in Debian [3].

I am reimplementing slirpvde[4], porting it to libslirp.  The idea is to
release the new version also as a static binary, so I support Athos' request to
ship a static library in libslirp-dev.

Any news?

Thank you,

      renzo

[1] https://wiki.virtualsquare.org
[2] https://wiki.virtualsquare.org/#/tutorials/vdebasics
[3] https://qa.debian.org/developer.php?login=virtualsquare%40cs.unibo.it
[4] https://www.huge-man-linux.net/man1/slirpvde.html