Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1049922: libslirp-dev: Ship a static library in libslirp-dev
47 views
Skip to first unread message
Athos Ribeiro
Aug 16, 2023, 4:40:05 PM8/16/23
to
Package: libslirp-dev
Severity: normal
Tags: patch
X-Debbugs-Cc: athos....@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!
Severity: normal
Tags: patch
X-Debbugs-Cc: athos....@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!
Michael Tokarev
Aug 16, 2023, 4:50:04 PM8/16/23
to
16.08.2023 23:33, Athos Ribeiro wrote:
> Package: libslirp-dev
> Severity: normal
> Tags: patch
> X-Debbugs-Cc: athos....@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?
> Package: libslirp-dev
> Severity: normal
> Tags: patch
> X-Debbugs-Cc: athos....@canonical.com
>
> Dear Maintainer,
>
> The following bug was reported for libslirp in ubuntu:
> https://bugs.launchpad.net/ubuntu/+source/libslirp/+bug/2029431
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
It's trivial to build a static library in addition to regular shared. But I
really want to understand the reasoning.
/mjt
Athos Ribeiro
Aug 16, 2023, 7:30:05 PM8/16/23
to
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,
>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.
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.
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
Michael Tokarev
Aug 17, 2023, 4:00:06 AM8/17/23
to
17.08.2023 02:23, Athos Ribeiro wrote:
..
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
..
> 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
> 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).
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
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?
(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?
> 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
least this should be accomplished with Reopen: #981893.
/mjt
Athos Ribeiro
Aug 17, 2023, 9:00:05 AM8/17/23
to
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.
>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.
>
>>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).
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.
https://salsa.debian.org/qemu-team/libslirp/-/merge_requests/2/diffs#62c82f62d2982134f9103384374819b97e418bca_4_4
--
Athos Ribeiro
Renzo Davoli
Jan 21, 2024, 12:10:05 PM1/21/24
to
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
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
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
0 new messages