Bug#1049922: libslirp-dev: Ship a static library in libslirp-dev
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
Bug#1049922: libslirp-dev: Ship a static library in libslirp-dev
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
Bug#1049922: libslirp-dev: Ship a static library in libslirp-dev
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
Bug#1049922: libslirp-dev: Ship a static library in libslirp-dev
On Wed, Aug 16, 2023 at 11:46:05PM +0300, Michael Tokarev wrote:
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.
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?
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?
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
--
Athos Ribeiro
Bug#1049922: libslirp-dev: Ship a static library in libslirp-dev
16.08.2023 23:33, Athos Ribeiro wrote: Package: libslirp-dev Severity: normal Tags: patch X-Debbugs-Cc: athos.ribe...@canonical.com Dear Maintainer, The following bug was reported for libslirp in ubuntu: https://bugs.launchpad.net/ubuntu/+source/libslirp/+bug/2029431 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. 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 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
Bug#1049922: libslirp-dev: Ship a static library in libslirp-dev
Package: libslirp-dev Severity: normal Tags: patch X-Debbugs-Cc: athos.ribe...@canonical.com 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!
