Create a 'bindist' package containing precompiled binaries and install script for Ubuntu 24.04 Linux

[jafingerhut]

'distbin' is the term used by Bryan at the September TST meeting, which I understand (perhaps incorrectly) to be one or more precompiled binaries, an install script, and any other files needed so that someone can download a single file, and within one or a few commands have an executable installation of p4c, simple_switch_grpc (the binary executable name of the BMv2 / behavioral-model software switch), and anything else required to run those programs on a system, without having to build from source.

As an example of a Bash script that clones several p4lang repositories and builds them from source code, and installs things in /usr/local/{bin,lib} and perhaps a few other places on a system, see these:

• https://github.com/p4lang/tutorials/blob/master/vm-ubuntu-24.04/install.sh
• https://github.com/p4lang/tutorials/blob/master/vm-ubuntu-24.04/install-p4dev-v8.sh

That has been tested with the latest versions of source for 4 p4lang repositories as of Sep 1, 2025, and builds everything without errors the last time I tried on that date, on an Ubuntu 24.04 Linux system. Most or all of it might work on Ubuntu 22.04 as well, and there might be vestiges of old Fedora Linux support in it, but any Fedora parts haven't been tested in a couple of years, and probably stale.

[jafingerhut]

@chreekat @fruffy I have created this issue after the TST meeting earlier today, and added a new label automation. This is the first issue on this repo I have added that label to. @fruffy I am guessing there might be a few other issues in this repo that you would want to add that label to.

[fruffy]

@chreekat @fruffy I have created this issue after the TST meeting earlier today, and added a new label automation. This is the first issue on this repo I have added that label to. @fruffy I am guessing there might be a few other issues in this repo that you would want to add that label to.

I would just use the infrastructure label? At least we have filed all projects related to CI and CI-adjacent tasks under that.

[jafingerhut]

Replaced label automation with label infrastructure.

[chreekat]

Small correction - it's "bindist" as in "binary distribution". :) (As opposed to sdist or "source distribution", which is a tarball of the source code and a README for building the project from scratch.)

I think a good visualization of the "end game" is like the following. As upstream (i.e., you) works from left-to-right, it'll be more likely that 3rd parties will meet you in the middle moving right-to-left. It sounds like this is already happening with NixOS and Arch users.

flowchart LR
    A[Git repository] --> B["Source distribution (sdist)"]
    B --> C["Binary distributions (bindists), 'relocatable', Linux x86, Linux aarch64, Apple M1, ..."]
    B --> D["OS-specific packages"]
    B --> E["Build from scratch"]

    D --> D1[Debian/Ubuntu .deb package]
    D --> D2[Fedora/RHEL .rpm package]
    D --> D3["Homebrew formula (macOS)"]
    D --> D4["Windows installer (MSI/EXE)"]

    A --> T[Reusable testsuite]
    T -.-> C
    T -.-> D
    T -.-> E

Loading

[Anamika1608]

hey @fruffy @jafingerhut, as i read this issue. it requires the three tasks to be done.

1. Binary distribution (bindist) - A .tar.gz with pre-compiled binaries
2. OS-specific packages (.deb, .rpm, Homebrew) - Integrates with the OS package manager
3. Reusable test suite - A set of tests that can verify any installation works correctly

i'm first starting with the binary distribution (would be great if we open up the separate issues for the 2nd and 3rd point)

I spent some time analyzing the existing build infrastructure across the repos to understand what we're working with and what's missing. Here's what I found:

What already exists in p4c:

• Static build support via STATIC_BUILD_WITH_DYNAMIC_GLIBC=ON which produces binaries that only depend on glibc (no libboost, libstdc++ etc). This is already tested in CI but only on Ubuntu 22.04, not
  24.04.
• CPack is already included in the root CMakeLists.txt, but only configured for source tarballs (make dist), not binary packages.
• The Tofino backend (backends/tofino/) already has a working binary CPack configuration with a packaging script. So there's a pattern to follow within the same codebase.
• The tools/debian-build/ directory has .deb packaging infrastructure (though it looks like it hasn't been updated in a while).

What's missing:

• No CMAKE_INSTALL_RPATH is set anywhere in p4c. This means installed binaries are not relocatable, they won't find their shared libraries if moved to a different location. For a proper bindist we'd
  need $ORIGIN/../lib style RPATH.
• behavioral-model uses autotools and has no static linking option. Its binaries dynamically link against thrift, nanomsg, boost, PI, grpc etc. We'd need to either bundle these shared libraries alongside
  the binaries, or require users to install them via apt at install time.
• No binary CPack variables are configured in the main p4c project (only source packaging).

How other compiler projects handle this:
I looked at how LLVM, GHC, Go and Rust distribute precompiled binaries. LLVM's approach seems most relevant since p4c is also a CMake-based compiler:

• LLVM ships a .tar.xz with bin/, lib/, include/, share/ directories
• Binaries use $ORIGIN/../lib RPATH so the whole tree is relocatable (extract anywhere and it works)
• They use CPack with TXZ generator to produce the archive
• Built on ubuntu-22.04 in GitHub Actions for broad glibc compatibility
• No install script needed, just extract and add bin/ to PATH

Proposed approach for the p4 bindist:

The output would be something like p4-bindist-ubuntu2404-x86_64.tar.gz containing:
p4-bindist/
bin/ (p4c, p4c-bm2-ss, simple_switch_grpc, simple_switch_CLI, etc.)
lib/ (bundled shared libs for behavioral-model deps)
share/p4c/ (p4include files, driver configs)
install.sh (optional: installs runtime apt deps, copies to /usr/local)

The build process would be:

1. Build p4c with STATIC_BUILD_WITH_DYNAMIC_GLIBC=ON on Ubuntu 24.04 (extending what CI already does on 22.04)
2. Build behavioral-model with PI, thrift, nanomsg and bundle the shared libraries alongside
3. Set RPATH on all binaries so they find libs relative to themselves
4. Package everything with CPack or a simple tar script
5. Automate via GitHub Actions, publish as release artifact

I do have certain questions:

1. Should the bindist be fully self-contained (bundle all shared libs, user just extracts and runs) or is it okay to require apt install for some runtime dependencies like libboost, libgmp, libpcap?

2. Should this live in the tutorials repo (since the install scripts are already there), in p4c, or in a new repo?

3. For scope, should the first version include just p4c + behavioral-model (simple_switch_grpc)? Or also mininet, PTF, p4runtime-shell?

4. The static build CI currently runs on Ubuntu 22.04. Any known issues with running it on 24.04?

5. Is there a preference on install prefix? /usr/local (standard), /opt/p4 (isolated), or fully relocatable (user chooses)?

Happy to start working on this once we align on the direction.

[jafingerhut]

@Anamika1608 Thanks for the detailed comment.

Regarding your questions, others are likely to have answers based on more knowledge of this than I have, but I'll give it a shot anyway:

1. If there are runtime dependencies with widely available and supported installable packages, e.g. libpcap, it seems very reasonable to me to require that someone install those on their system, especially if the bindist includes instructions or a simple install script that can install those packages for them.

2. @fruffy any thoughts on this question? We could put such things in the tutorials repo, but I would not be surprised if you have a better idea.

3. Just p4c + behavioral-model is a great start. I am pretty confident that installing mininet, PTF, and p4runtime-shell via a simple bash script after the bindist is installed can be made to work well.

4. None that I know of, but I have never tried.

5. If fully relocatable is not much more difficult, that seems good, but /usr/local is also good.

[Anamika1608]

@jafingerhut Thanks for the answers, this clears up a lot.

Based on this, here's where I'm landing on the design:

• Runtime dependencies: I'll split them into two categories. Standard libs available in Ubuntu 24.04's apt repos (libboost, libgmp, libpcap, libprotobuf, libgrpc) will be installed via a small install script included in the bindist. But things like thrift 0.16, nanomsg 1.0, and PI libraries aren't available as apt packages on Ubuntu 24.04, so those will need to be bundled inside the tarball itself.

• Scope: p4c + behavioral-model (simple_switch, simple_switch_grpc, simple_switch_CLI) for the first version. I'll keep the structure extensible so mininet/PTF/p4runtime-shell can be added later without reworking things.

• Relocatability: I looked into this and the main cost is setting $ORIGIN/../lib as RPATH on all binaries. For p4c this is just a CMake variable (CMAKE_INSTALL_RPATH). For behavioral-model it would need patchelf post-build since it uses autotools. It's not a huge amount of extra work, so I'll aim for relocatable from the start. That way the bindist works both as "extract anywhere and use" and as "extract and copy to /usr/local".

maybe i can try building p4c with STATIC_BUILD_WITH_DYNAMIC_GLIBC=ON on Ubuntu 24.04 inside a Docker container to see if it works (since CI only tests this on 22.04 currently). That will tell me quickly if there are any blockers.

@fruffy would love to hear your thoughts on where this should live repo-wise, and if you see any issues with this approach.

[fruffy]

@fruffy would love to hear your thoughts on where this should live repo-wise, and if you see any issues with this approach.

It's okay to put this into tutorials for now. At some point we need a repository for all this kind of infra work.