Ack.
Take a look at .../extras/snap/snapcraft.yaml. I haven't built the vpp snap
in a while, but this scheme (or the flatpack / appimage equivalent) finesses
the multiple libc problem.
There's a 0.0% chance that /bin/date will suddenly break. Been there, done
that.
D.
From: vpp-d
Hi,
As the person who's been submitting most of these patches recently, my interest
is not the size of the resulting VPP binary/image, but instead the fact that
the embedded systems I'm attempting to build VPP on simply do not use glibc at
all -- they use musl as the system libc. I'm much more
Hello,
Status update:
For better stability of verify vpp-csit-device job, I decided to silence one of
the test that was randomly failing ipv6-vm until full root cause is identified
and cleared.
Peter Mikus
Engineer – Software
Cisco Systems Limited
From
Dave,
Any chance we could get vpp down to a single statically linked binary?
That's roughly the way things are trending with Go... and it has a lot of
very very nice advantages in a containerized Cloud Native world.
Ed
On Thu, Jan 21, 2021 at 2:11 PM Dave Barach wrote:
> I've been down this pa
I've been down this path before.
s/glibc/musl/ fixes one set of issues, and a small set at that. [Back in the
good old days, vpp wasn't even linked against glibc.]
Here's a quick library summary:
$ ldd /usr/bin/vpp
linux-vdso.so.1 (0x7ffef81f2000)
libvlibmemory.so.21.06 =>
/
Hi everyone,
There is some on-going work to make VPP works with musl libc instead of glibc:
https://gerrit.fd.io/r/q/topic:%22musl%22+(status:open%20OR%20status:merged)
The goal is to be able to run VPP on embedded platforms relying on musl.
The modifications are overall pretty small, but we'd li
Hello,
Status update:
Today I have found one of the resource bottleneck being csit-shim container
causing majority of OOM failures on vpp-device job.
I fixed/increase the capacity of memory allocated to this container handling
reservation API.
I restarted machines to ensure everything is starte
