Provide static library in libslirp-dev

Status changed to 'Confirmed' because the bug affects multiple users.

Re: Qemu static builds... Qemu 7.2+ https://wiki.qemu.org/ChangeLog/7.2#SLIRP_module_(user-mode_networking) does not include slirp any longer and expects the host environment to include it.

I am ultimately looking for instructions on how to create a static qemu build to emulate RaspPi 3 on bullseye. Based on the work here https://github.com/lukechilds/dockerpi which runs ok for QEMU <=6.x.x for RaspPi 2,3.

I've noticed, libslirp0 should have the library file. (https://salsa.debian.org/qemu-team/libslirp/-/blob/master/debian/control#L13).

Including libslirp0 ubuntu package before building qemu doesn't seem to resolve the error...

From https://www.qemu.org/docs/master/devel/build-system.html - configuring qemu to produce statically linked executable for ARM target with slirp.

```
configure --static --disable-gio --enable-slirp --target-list=arm-softmmu,aarch64-softmmu
```
...
#0 332.4 [1990/3099] Linking target qemu-system-arm
#0 332.4 FAILED: qemu-system-arm
#0 332.4 c++ -m64 -mcx16 @qemu-system-arm.rsp
#0 332.4 /usr/bin/ld: cannot find -lslirp: No such file or directory
#0 332.4 collect2: error: ld returned 1 exit status
...
ERROR: failed to solve: process "/bin/sh -c ../qemu-${QEMU_VERSION}/configure --static --disable-gio --enable-slirp --target-list=arm-softmmu,aarch64-softmmu" did not complete successfully: exit code: 1
```

As original post implies, --enable-slirp=git (or system) are not supported any longer despite qemu and slirp documentation mentioning it. (https://gitlab.freedesktop.org/slirp/libslirp#building)

What's the reason you're building static qemu-system to begin with?

This bug was fixed in the package libslirp - 4.7.0-1ubuntu1

---------------
libslirp (4.7.0-1ubuntu1) mantic; urgency=medium

  * d/rules, d/libslirp-dev.install: ship static library in the libslirp-dev
    binary package. (LP: #2029431)

 -- Athos Ribeiro <email address hidden> Wed, 16 Aug 2023 14:36:41 -0300

Great! Thanks. Can this be backported to Ubuntu Jammy?

Hi Michael Cook,

Would you mind addressing Michael Tokarev's question on your use case for this request ?

Note that this could help making a case for a possible SRU.

Sure, in https://bugs.launchpad.net/ubuntu/+source/libslirp/+bug/2029431/comments/3 I mentioned that I'm trying to build a qemu based raspberry pi with newer versions (dockerpi) with the hope to create a virtual RaspPi 4 that can run in a small, lean docker container. (I know qemu doesn't have platform support for Rasp4 yet).

The dockerpi project worked, pre-Qemu 7.2 but now fails. It is building a static and stripped qemu executable which ends up working well and in a very small container image.

My attempts to build a non-static dockerpi container fail because libslirp and emulated networking is missing (libslirp). In addition, the end result container is many times (10x) the size of the original container that includes the static qemu which is impractical as I wish to run a fleet of qemu-based RaspPis in a k8s cluster or swarm.

It seemed, the easiest route was to re-introduce the static qemu in this libslirp library in the dockerpi project. Maybe I'm still missing something fundamental so please feel free to enlighten me ;o)

btw, Michael, can't you omit libslirp? It is slow and quite fat by its own with all the networking emulation and guesswork, it is much faster to use tap networking with qemu. Especially together with docker or k8s, which already has bridges and taps set up.

I am not sure what I can omit or include. When I omitted it, RaspPi image booted up and died when it couldn't find any "net" interfaces. Do you have any pointers to using a tap networking interface with qemu and docker? I am willing to give it a go, but learning as I go here.

Is it particularly difficult or time consuming to provide it or what's the
push back? From what I could tell it's not hard to get the build system too
produce both static + dynamic when you build it yourself.

I'll be honest I gave up on my static qemu system (too many other
dependencies that required dynamic for my build) but I do see others
patching & building it or turning off just the right features.

I think "small binary + I want this feature" is a legitimate use case.

On Fri, Aug 18, 2023, 18:36 Michael Cook <email address hidden> wrote:

> I am not sure what I can omit or include. When I omitted it, RaspPi
> image booted up and died when it couldn't find any "net" interfaces. Do
> you have any pointers to using a tap networking interface with qemu and
> docker? I am willing to give it a go, but learning as I go here.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/2029431
>
> Title:
> Provide static library in libslirp-dev
>
> Status in libslirp package in Ubuntu:
> Fix Released
> Status in libslirp package in Debian:
> Unknown
>
> Bug description:
> QEMU static builds currently fail (among other reasons) because a
> static libslirp is missing from libslirp-dev, as is usual for other
> *-dev packages.
>
> The instructions in https://gitlab.freedesktop.org/slirp/libslirp --
> which say to "(QEMU may build with the submodule static library using
> --enable-slirp=git)" -- do not work anymore as of the patches in
> https://patchwork.kernel.org/project/qemu-
> <email address hidden>/ which removed
> those options completely.
>
> It'd be best if a static library was just provided in every libslirp-
> dev package.
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/libslirp/+bug/2029431/+subscriptions
>
>

This is fixed in Mantic. I am unsure if this specific change would be acceptable by the SRU team since one could easily use the delta added in mantic to rebuild the package locally to get the static library file.

If even though any one of you (or anyone else affected) would like to follow through with the SRU process, please check the require process at https://wiki.ubuntu.com/StableReleaseUpdates.

I would be happy to sponsor uploads and guide you through the process.

I think is easy to be done and agree to the tag as bitesize, I talked to SRU people and they said this would be ok from an SRU POV.

The only thing that holds this back is that it is just such a niche use-case that it is of low priority and there always feels there is something more important to tackle.

I did create this before my day officially started and pushed it to a PPA.
Now did a 1 minute check if the PPA behaves as expected and submitted the PR for review.

Once approved that can go to the SRU queue to fix it in jammy.

Reviewed by Athos and uploaded, waiting for the SRU team to find time for it.

> I think is easy to be done and agree to the tag as bitesize, I talked to
> SRU people and they said this would be ok from an SRU POV.

Well, you don't say who you talked to; perhaps whoever you did talk to wants to process this SRU.

For my part, I think the 'importance: wishlist' is accurate and therefore this doesn't meet the threshold of an SRU in terms of cost/benefit. Nothing in this bug indicates it's needed for Ubuntu, the use case is for static builds of qemu and we provide supported dynamically-linked builds of qemu (which do use libslirp).

> Well, you don't say who you talked to; perhaps whoever you did talk to wants to process this SRU.

I talked to Robie but since posting he sent me "That's not what I said!" so I must have misunderstood him. Your answer made us sort this out in more depth which is helpful - thank you Steve!

First let me summarize the discussion we had for full transparency:
R: Assuming the patch is trivial and obviously low risk, I don't see a massive problem with it in an SRU. I would question though why we're spending effort on it. Is there a reason we should care more about this than for something that will only benefit one person?
C: I think it benefits a class of people. But I'd still think the full number of people benefiting is only two digit
R: It's still weird though. For example, if for a Docker image, why can't they base it on Mantic?
C: it would even be needed just for a static build using slirp (without docker or any such)
R: That's not the reported user story though?
C: I'm mostly +0.75 as I think it is such few work
C: Here is my proposal, if you say it is not a pre-nack by SRU we can have anyone looking for a bitesize thing at it
C: So we'd not spend effort on it now, but when anyone we mentor needs training this is a good candidate
R: It is not a pre-nack from me.
R: Though if it's more than a few weeks the value of landing it at all diminishes significantly
R: That might have already happened.
R: (the value having diminished I mean)

From there on I mostly had a bad feeling as it was so trivial to fix and so low regression for others that I had a hard time finding any good “this is why we are not doing it”. But OTOH I completely agree that it shouldn’t be Canonical effort spent, there are more urgent things.

So I decided to prepare the upload in my private time on a morning before I started work - and so it got into the -unapproved queue.

> For my part, I think the 'importance: wishlist' is accurate and therefore this doesn't meet the threshold of an SRU in terms of cost/benefit.

That threshold I didn’t consider sufficiently, sorry for that.

I thought my talk with Robie would have covered it, but in hindsight it didn’t.

Quote from our clarification run: “I would add that from my perspective (sorry if it wasn't well communicated) what I meant was that I didn't feel that a compelling user story had been established that justified the SRU, but I saw nothing else that would block it, so I didn't intend for our conversation to imply that I was blocking it. But nor was I saying +1 because of the lack of that story.“

So now overall this case is now blocked at not passing this threshold until one makes a more compelling case to convince the SRU team.
We could at least mark it block-proposed to keep it there to be picked up by any other future change exceeding that threshold - WDYT?
I'll mark it that way, feel free to correct/change

> Nothing in this bug indicates it's needed for Ubuntu

It is not needed for Ubuntu itself, only for Ubuntu users that want to create static builds using libslirp.

FYI: Added block-proposed so it would not migrate on its own

Hello Chris, or anyone else affected,

Accepted libslirp into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libslirp/4.6.1-1ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Verification step 1
Without fix the system behaves as expected, able to build dynamic, but failing to static link

root@j:~# cat simpleslirp.c
#include <stdio.h>
#include <stdlib.h>
#include "libslirp.h"

int main(int argc, char *argv[]) {
    printf("Slirp version %s\n", slirp_version_string());
}
root@j:~# apt-cache policy libslirp-dev
libslirp-dev:
  Installed: 4.6.1-1build1
  Candidate: 4.6.1-1ubuntu0.1
  Version table:
     4.6.1-1ubuntu0.1 500
        500 http://archive.ubuntu.com/ubuntu jammy-proposed/main amd64 Packages
 *** 4.6.1-1build1 500
        500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages
        100 /var/lib/dpkg/status
root@j:~# gcc simpleslirp.c $(pkg-config --libs slirp) $(pkg-config --cflags slirp) -o simpleslirp
root@j:~# ldd ./simpleslirp | grep slirp
 libslirp.so.0 => /lib/x86_64-linux-gnu/libslirp.so.0 (0x00007f02dc243000)
root@j:~# ./simpleslirp
Slirp version 4.6.1

root@j:~# gcc simpleslirp.c $(pkg-config --libs slirp) $(pkg-config --cflags --static slirp) -static -o simpleslirp
/usr/bin/ld: cannot find -lslirp: No such file or directory
collect2: error: ld returned 1 exit status

Verification step 2

root@j:~# apt-cache policy libslirp-dev
libslirp-dev:
  Installed: 4.6.1-1build1
  Candidate: 4.6.1-1ubuntu0.1
  Version table:
     4.6.1-1ubuntu0.1 500
        500 http://archive.ubuntu.com/ubuntu jammy-proposed/main amd64 Packages
 *** 4.6.1-1build1 500
        500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages
        100 /var/lib/dpkg/status

Upgrade to proposed

root@j:~# apt install libslirp-dev libslirp0
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be upgraded:
  libslirp-dev libslirp0
2 upgraded, 0 newly installed, 0 to remove and 30 not upgraded.
Need to get 138 kB of archives.
After this operation, 262 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu jammy-proposed/main amd64 libslirp-dev amd64 4.6.1-1ubuntu0.1 [76.1 kB]
Get:2 http://archive.ubuntu.com/ubuntu jammy-proposed/main amd64 libslirp0 amd64 4.6.1-1ubuntu0.1 [61.6 kB]
Fetched 138 kB in 0s (712 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 38662 files and directories currently installed.)
Preparing to unpack .../libslirp-dev_4.6.1-1ubuntu0.1_amd64.deb ...
Unpacking libslirp-dev:amd64 (4.6.1-1ubuntu0.1) over (4.6.1-1build1) ...
Preparing to unpack .../libslirp0_4.6.1-1ubuntu0.1_amd64.deb ...
Unpacking libslirp0:amd64 (4.6.1-1ubuntu0.1) over (4.6.1-1build1) ...
Setting up libslirp0:amd64 (4.6.1-1ubuntu0.1) ...
Setting up libslirp-dev:amd64 (4.6.1-1ubuntu0.1) ...
Processing triggers for libc-bin (2.35-0ubuntu3.6) ...
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 78.)
debconf: falling back to frontend: Readline
Scanning processes...
Scanning candidates...

Restarting services...

Verification step 3

Check old behavior as well as the new fixed one ...

root@j:~# apt-cache policy libslirp-dev libslirp0
libslirp-dev:
  Installed: 4.6.1-1ubuntu0.1
  Candidate: 4.6.1-1ubuntu0.1
  Version table:
 *** 4.6.1-1ubuntu0.1 500
        500 http://archive.ubuntu.com/ubuntu jammy-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     4.6.1-1build1 500
        500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages
libslirp0:
  Installed: 4.6.1-1ubuntu0.1
  Candidate: 4.6.1-1ubuntu0.1
  Version table:
 *** 4.6.1-1ubuntu0.1 500
        500 http://archive.ubuntu.com/ubuntu jammy-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     4.6.1-1build1 500
        500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages

root@j:~# cat simpleslirp.c
#include <stdio.h>
#include <stdlib.h>
#include "libslirp.h"

int main(int argc, char *argv[]) {
    printf("Slirp version %s\n", slirp_version_string());
}
root@j:~# gcc simpleslirp.c $(pkg-config --libs slirp) $(pkg-config --cflags slirp) -o simpleslirp
root@j:~# ldd simpleslirp | grep slirp
 libslirp.so.0 => /lib/x86_64-linux-gnu/libslirp.so.0 (0x00007f665fb71000)
root@j:~# ./simpleslirp
Slirp version 4.6.1
root@j:~#
root@j:~#
root@j:~# gcc simpleslirp.c $(pkg-config --libs slirp) $(pkg-config --cflags --static slirp) -static -o simpleslirp
root@j:~# ldd simpleslirp
 not a dynamic executable
root@j:~# ./simpleslirp
Slirp version 4.6.1

=> Working for dynamic linking just as before, and now is also able to provide static linking.
=> setting as verified

Being a fully verified wishlist item intentionally held in block-proposed this will hang there for a while.
I'll unsubscribe ubuntu-server as there is nothing left to act on for now.

I hope a future fix or security update will pick it up soon ...

If you don't want released for a specific series the correct tag is block-proposed-$series. I've tagged this blocked-proposed-jammy given what I think the intent here is.