ci: Build statically linked bpf-linker in CI #215

vadorovsky · 2024-08-02T15:36:31Z

Download LLVM builds from Rust CI.
Always link libLLVM statically.
For now, do it only for x86_64.

This change is

.github/workflows/release.yml

.github/workflows/ci.yml

Cargo.lock

.github/workflows/llvm.yml

.github/workflows/ci.yml

.github/workflows/llvm.yml

- Update kernel images for virtualized tests. - Add local integration tests, runners have recent enough kernel to be able to run them now. - Remove the comment which propsoes removal of virtualized tests. They are actually convenient for testing different kernel versions and are going to be useful for cross-compilation, which is proposed in aya-rs#215.

tamird

Reviewed 1 of 6 files at r5, 2 of 3 files at r6, 3 of 5 files at r7, 4 of 5 files at r8, all commit messages.
Dismissed @vadorovsky from a discussion.
Reviewable status: 4 of 8 files reviewed, 18 unresolved discussions (waiting on @vadorovsky)

Cargo.lock line 428 at r7 (raw file):

dependencies = [
 "cfg-if",
 "windows-targets 0.48.5",

undo?

.github/workflows/ci.yml line 67 at r7 (raw file):

            target: x86_64-apple-darwin
            target-llvm: x86_64-apple-darwin
          # We use the GNU builds of LLVM both for GNU and musl builds of

Is this just to reduce how many times we need to build LLVM or what's the benefit?

.github/workflows/ci.yml line 59 at r8 (raw file):

          - beta
          - nightly
        # We don't use ubuntu-latest because we care about the apt packages available.

This should be anchored on an instance of ubuntu-22.04

.github/workflows/ci.yml line 61 at r8 (raw file):

        # We don't use ubuntu-latest because we care about the apt packages available.
        target:
          - os: macos-14

Can we add a comment about why we can't cross-compile for these apple targets?

.github/workflows/ci.yml line 87 at r8 (raw file):

      - uses: Swatinem/rust-cache@v2

      - name: Check (default features, no system LLVM)

did this need to move? we intentionally do this here before we've set up LLVM

.github/workflows/ci.yml line 101 at r8 (raw file):

      CARGO_TARGET_AARCH64_UNKNOWN_LINUX_GNU_RUNNER: qemu-aarch64 -L /usr/aarch64-linux-gnu
      CARGO_TARGET_AARCH64_UNKNOWN_LINUX_MUSL_RUNNER: qemu-aarch64 -L /usr/aarch64-linux-gnu
      CARGO_TARGET_RISCV64GC_UNKNOWN_LINUX_GNU_RUNNER: qemu-aarch64 -L /usr/riscv64-linux-gnu

🤔 RISC64 on qemu-aarch64?

how come all these env vars are needed in addition to the content of .cargo/config.toml?

.github/workflows/ci.yml line 154 at r8 (raw file):

          fail-on-cache-miss: true

      - name: Point llvm-sys to the restored LLVM

nit: no long specific to llvm-sys

.github/workflows/ci.yml line 164 at r8 (raw file):

          echo "RUSTFLAGS=$rustflags" >> $GITHUB_ENV

      # llvm-sys discovers link flags at build script time; these are cached by cargo. The cached

this can probably be removed now? I'd expect RUSTFLAGS to bust the cargo cache

.github/workflows/ci.yml line 193 at r8 (raw file):

      - name: Install
        if: matrix.rust == 'nightly'
        run: cargo install --path . --no-default-features

don't we need/want no-llvm-linking here too?

.github/workflows/llvm.yml line 19 at r6 (raw file):

jobs:
  llvm:
    runs-on: ${{ matrix.os }}

Can we add a comment about why we can't cross-compile for these apple targets?

.github/workflows/llvm.yml line 101 at r8 (raw file):

      - name: Install Tools
        if: runner.os == 'macOS' && steps.cache-llvm.outputs.cache-hit != 'true'
        # TODO(vadorovsky): There are LLVM binary tarballs for macOS on GitHub,

i think this TODO can go? unclear why we need the latest LLVM, we just need something reasonably recent. In fact we might not need this at all, there's already a clang on mac runners. Maybe we just need ninja.

.github/workflows/llvm.yml line 114 at r8 (raw file):

          echo $(brew --prefix)/opt/llvm/bin >> $GITHUB_PATH

      - name: Install LLVM

🤔 I think we no longer want this, we're building from source

.github/workflows/llvm.yml line 154 at r8 (raw file):

            -DCMAKE_SYSTEM_NAME="${{ matrix.system }}" \
            -DCMAKE_SYSTEM_PROCESSOR="${{ matrix.processor }}" \
            -DLLVM_BUILD_LLVM_DYLIB=ON \

I think we want static libraries, no?

.github/workflows/llvm.yml line 159 at r8 (raw file):

            -DLLVM_ENABLE_RUNTIMES= \
            -DLLVM_HOST_TRIPLE="${{ matrix.target }}" \
            -DLLVM_INSTALL_UTILS=ON \

we can probably remove?

.github/workflows/release.yml line 12 at r8 (raw file):

  upload-bins:
    runs-on: ${{ matrix.os }}

same here, why can't we always run on linux and cross compile?

tests/tests.rs line 96 at r8 (raw file):

}

// bpftool doesn't work on macOS, skip the tests requiring it.

https://github.com/anakryiko/btfdump

build.rs line 16 at r7 (raw file):

    let libdir_path = Path::new(&libdir);
    if !libdir_path.exists() {
        panic!("Directory {} does not exist", libdir);

nit: not known it's a directory at this stage

build.rs line 44 at r7 (raw file):

            let lib_name = &file_name[3..file_name.len() - 2];
            println!("cargo:rustc-link-lib=static={}", lib_name);
        }

if let Some(lib_name) = || {
        let file_name = path.file_name()?;
        let file_name = file_name.to_str()?;
        let file_name = file_name.strip_prefix("lib")?;
        let file_name = file_name.strip_suffix("a")?;
        Some(file_name)
}() {
            println!("cargo:rustc-link-lib=static={}", lib_name);
}

Code quote:

        let ext = match path.extension() {
            Some(ext) => ext,
            None => continue,
        };
        if ext != "a" {
            continue;
        }

        let file_name = match path.file_name() {
            Some(file_name) => file_name,
            None => continue,
        };
        let file_name = match file_name.to_str() {
            Some(file_name) => file_name,
            None => continue,
        };
        // Strip "lib" prefix and ".a" suffix.
        if file_name.starts_with("lib") && file_name.ends_with(".a") {
            let lib_name = &file_name[3..file_name.len() - 2];
            println!("cargo:rustc-link-lib=static={}", lib_name);
        }

vadorovsky

Reviewable status: 4 of 8 files reviewed, 18 unresolved discussions (waiting on @tamird)

.github/workflows/ci.yml line 67 at r7 (raw file):

Previously, tamird (Tamir Duberstein) wrote…

Is this just to reduce how many times we need to build LLVM or what's the benefit?

I thought that reducing the times we need to build LLVM would be a benefit, yes.

However, I think I will have to add the musl builds of LLVM... https://github.com/aya-rs/bpf-linker/actions/runs/11071032289/job/30765139812?pr=215

.github/workflows/ci.yml line 101 at r8 (raw file):

Previously, tamird (Tamir Duberstein) wrote…

🤔 RISC64 on qemu-aarch64?

how come all these env vars are needed in addition to the content of .cargo/config.toml?

Whoops, good catch.

I will probably remove the qemu runners from the content of .cargo/config.toml and stick to the env vars - we shouldn't require QEMU in case someone is performing a native build on arm64 or RISC-V. WDYT?

I actually caught myself on having to overwrite to comment the content of .cargo/config.toml myself when building bpf-linker on my Macbook on Asahi. :v

build.rs line 16 at r7 (raw file):

Previously, tamird (Tamir Duberstein) wrote…

nit: not known it's a directory at this stage

I removed this file. After giving it a thought, I think we should still rely on the llvm-sys's build.rs and llvm-config if someone is installing bpf-linker using cargo install bpf-linker --no-default-features. We should probably use no-llvm-linking only for our cross-compilation purpose.

vadorovsky

Reviewable status: 4 of 8 files reviewed, 18 unresolved discussions (waiting on @tamird)

.github/workflows/llvm.yml line 154 at r8 (raw file):

Previously, tamird (Tamir Duberstein) wrote…

I think we want static libraries, no?

This option doesn't disable static libraries, it provides the dynamic ones. I kept that option just to reduce the size of util binaries.

But given your comment below and the fact we're getting rid of llvm-config, I will try removing it.

vadorovsky

Reviewable status: 4 of 8 files reviewed, 18 unresolved discussions (waiting on @tamird)

.github/workflows/release.yml line 12 at r8 (raw file):

Previously, tamird (Tamir Duberstein) wrote…

same here, why can't we always run on linux and cross compile?

clang shipped in Ubuntu packages doesn't support cross-compilation to macOS targets:

-- Check for working C compiler: /usr/bin/clang - broken
CMake Error at /usr/share/cmake/Modules/CMakeTestCCompiler.cmake:67 (message):
  The C compiler

    "/usr/bin/clang"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: '/home/vadorovsky/src/llvm-project/build/CMakeFiles/CMakeScratch/TryCompile-boxxdE'

    Run Build Command(s): /usr/bin/ninja-build -v cmTC_f8be6
    [1/2] /usr/bin/clang --target=aarch64-apple-darwin    -MD -MT CMakeFiles/cmTC_f8be6.dir/testCCompiler.c.o -MF CMakeFiles/cmTC_f8be6.dir/testCCompiler.c.o.d -o CMakeFiles/cmTC_f8be6.dir/testCCompiler.c.o -c /home/vadorovsky/src/llvm-project/build/CMakeFiles/CMakeScratch/TryCompile-boxxdE/testCCompiler.c
    [2/2] : && /usr/bin/clang --target=aarch64-apple-darwin   CMakeFiles/cmTC_f8be6.dir/testCCompiler.c.o -o cmTC_f8be6   && :
    FAILED: cmTC_f8be6
    : && /usr/bin/clang --target=aarch64-apple-darwin   CMakeFiles/cmTC_f8be6.dir/testCCompiler.c.o -o cmTC_f8be6   && :
    /usr/bin/ld: unrecognised emulation mode: llvm
    Supported emulations: aarch64linux aarch64elf aarch64elf32 aarch64elf32b aarch64elfb armelf armelfb aarch64linuxb aarch64linux32 aarch64linux32b armelfb_linux_eabi armelf_linux_eabi i386pep i386pe elf64bpf
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    ninja: build stopped: subcommand failed.

tamird

Reviewable status: 4 of 8 files reviewed, 16 unresolved discussions (waiting on @vadorovsky)

.github/workflows/ci.yml line 67 at r7 (raw file):

Previously, vadorovsky (Michal Rostecki) wrote…

I thought that reducing the times we need to build LLVM would be a benefit, yes.

However, I think I will have to add the musl builds of LLVM... https://github.com/aya-rs/bpf-linker/actions/runs/11071032289/job/30765139812?pr=215

Yeah mixing libs c would be surprising if it worked.

.github/workflows/ci.yml line 101 at r8 (raw file):

Previously, vadorovsky (Michal Rostecki) wrote…

Whoops, good catch.

I will probably remove the qemu runners from the content of .cargo/config.toml and stick to the env vars - we shouldn't require QEMU in case someone is performing a native build on arm64 or RISC-V. WDYT?

I actually caught myself on having to overwrite to comment the content of .cargo/config.toml myself when building bpf-linker on my Macbook on Asahi. :v

Yeah, I think removing from .cargo/config.toml is sensible.

.github/workflows/llvm.yml line 154 at r8 (raw file):

Previously, vadorovsky (Michal Rostecki) wrote…

This option doesn't disable static libraries, it provides the dynamic ones. I kept that option just to reduce the size of util binaries.

But given your comment below and the fact we're getting rid of llvm-config, I will try removing it.

👍

.github/workflows/release.yml line 12 at r8 (raw file):

Previously, vadorovsky (Michal Rostecki) wrote…

clang shipped in Ubuntu packages doesn't support cross-compilation to macOS targets:

-- Check for working C compiler: /usr/bin/clang - broken
CMake Error at /usr/share/cmake/Modules/CMakeTestCCompiler.cmake:67 (message):
  The C compiler

    "/usr/bin/clang"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: '/home/vadorovsky/src/llvm-project/build/CMakeFiles/CMakeScratch/TryCompile-boxxdE'

    Run Build Command(s): /usr/bin/ninja-build -v cmTC_f8be6
    [1/2] /usr/bin/clang --target=aarch64-apple-darwin    -MD -MT CMakeFiles/cmTC_f8be6.dir/testCCompiler.c.o -MF CMakeFiles/cmTC_f8be6.dir/testCCompiler.c.o.d -o CMakeFiles/cmTC_f8be6.dir/testCCompiler.c.o -c /home/vadorovsky/src/llvm-project/build/CMakeFiles/CMakeScratch/TryCompile-boxxdE/testCCompiler.c
    [2/2] : && /usr/bin/clang --target=aarch64-apple-darwin   CMakeFiles/cmTC_f8be6.dir/testCCompiler.c.o -o cmTC_f8be6   && :
    FAILED: cmTC_f8be6
    : && /usr/bin/clang --target=aarch64-apple-darwin   CMakeFiles/cmTC_f8be6.dir/testCCompiler.c.o -o cmTC_f8be6   && :
    /usr/bin/ld: unrecognised emulation mode: llvm
    Supported emulations: aarch64linux aarch64elf aarch64elf32 aarch64elf32b aarch64elfb armelf armelfb aarch64linuxb aarch64linux32 aarch64linux32b armelfb_linux_eabi armelf_linux_eabi i386pep i386pe elf64bpf
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    ninja: build stopped: subcommand failed.

Looks like ld is the problem rather than clang. We already use lld to build LLVM (I forget why), does cross-compilation work if we use it instead of /usr/bin/ld?

vadorovsky

Reviewable status: 4 of 8 files reviewed, 16 unresolved discussions (waiting on @tamird)

.github/workflows/release.yml line 12 at r8 (raw file):

Previously, tamird (Tamir Duberstein) wrote…

Looks like ld is the problem rather than clang. We already use lld to build LLVM (I forget why), does cross-compilation work if we use it instead of /usr/bin/ld?

Right. And that failure happened in the CMake's compiler check rather than actual compilation of LLVM. I think that these compiler checks don't care about LLVM-specific flags, so -DLLVM_USE_LINKER=lld doesn't have any effect.

I tried suppressing the compiler checks with -DCMAKE_*_COMPILER_WORKS, but doing so seems to break further checks, defined by LLVM CMake configuration, which otherwise work without problems...

$ cmake -S llvm -B build -G Ninja -DCMAKE_BUILD_TYPE=Debug -DCMAKE_ASM_COMPILER=clang -DCMAKE_ASM_COMPILER_WORKS=ON -DCMAKE_ASM_COMPILER_TARGET=aarch64-apple-darwin -DCMAKE_C_COMPILER=clang -DCMAKE_C_COMPILER_WORKS=ON -DCMAKE_C_COMPILER_TARGET=aarch64-apple-darwin -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_CXX_COMPILER_WORKS=ON -DCMAKE_CXX_COMPILER_TARGET=aarch64-apple-darwin -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_PROJECTS= -DLLVM_ENABLE_RUNTIMES= -DLLVM_HOST_TRIPLE=aarch64-apple-darwin -DLLVM_INSTALL_UTILS=ON -DLLVM_TARGETS_TO_BUILD=BPF -DLLVM_USE_LINKER=lld
[...]
-- Performing Test LLVM_LIBSTDCXX_MIN
-- Performing Test LLVM_LIBSTDCXX_MIN - Failed
CMake Error at cmake/modules/CheckCompilerVersion.cmake:88 (message):
  libstdc++ version must be at least 7.4.
Call Stack (most recent call first):
  cmake/config-ix.cmake:16 (include)
  CMakeLists.txt:949 (include)


-- Configuring incomplete, errors occurred!
See also "/root/llvm/build/CMakeFiles/CMakeOutput.log".
See also "/root/llvm/build/CMakeFiles/CMakeError.log".

Then I tried an another trick, which is passing -DCMAKE_C(XX)_FLAGS=-fuse-ld=lld, but then it complains about the lack of macOS System library:

root@8167de35cca2:~/llvm# cmake -S llvm -B build -G Ninja -DCMAKE_BUILD_TYPE=Debug -DCMAKE_ASM_COMPILER=clang -DCMAKE_ASM_COMPILER_TARGET=aarch64-apple-darwin -DCMAKE_C_COMPILER=clang -DCMAKE_C_COMPILER_TARGET=aarch64-apple-darwin -DCMAKE_C_FLAGS=-fuse-ld=lld -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_CXX_COMPILER_TARGET=aarch64-apple-darwin -DCMAKE_CXX_FLAGS=-fuse-ld=lld -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_PROJECTS= -DLLVM_ENABLE_RUNTIMES= -DLLVM_HOST_TRIPLE=aarch64-apple-darwin -DLLVM_INSTALL_UTILS=ON -DLLVM_TARGETS_TO_BUILD=BPF -DLLVM_USE_LINKER=lld
[...]
-- Check for working C compiler: /usr/bin/clang
-- Check for working C compiler: /usr/bin/clang - broken
CMake Error at /usr/share/cmake-3.22/Modules/CMakeTestCCompiler.cmake:69 (message):
  The C compiler

    "/usr/bin/clang"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /root/llvm/build/CMakeFiles/CMakeTmp

    Run Build Command(s):/usr/bin/ninja cmTC_e5b80 && [1/2] Building C object CMakeFiles/cmTC_e5b80.dir/testCCompiler.c.o
    clang: warning: argument unused during compilation: '-fuse-ld=lld' [-Wunused-command-line-argument]
    [2/2] Linking C executable cmTC_e5b80
    FAILED: cmTC_e5b80
    : && /usr/bin/clang --target=aarch64-apple-darwin -fuse-ld=lld  CMakeFiles/cmTC_e5b80.dir/testCCompiler.c.o -o cmTC_e5b80   && :
    ld64.lld: error: library not found for -lSystem
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    ninja: build stopped: subcommand failed.

Not sure if the actual LLVM build would complain about lack of -lSystem, but at this point I don't think that the whole gymnastics to make this check work is worth it. Building on macOS runners works fine.

tamird

Reviewable status: 4 of 8 files reviewed, 16 unresolved discussions (waiting on @vadorovsky)

.github/workflows/release.yml line 12 at r8 (raw file):

Previously, vadorovsky (Michal Rostecki) wrote…

Right. And that failure happened in the CMake's compiler check rather than actual compilation of LLVM. I think that these compiler checks don't care about LLVM-specific flags, so -DLLVM_USE_LINKER=lld doesn't have any effect.

I tried suppressing the compiler checks with -DCMAKE_*_COMPILER_WORKS, but doing so seems to break further checks, defined by LLVM CMake configuration, which otherwise work without problems...

$ cmake -S llvm -B build -G Ninja -DCMAKE_BUILD_TYPE=Debug -DCMAKE_ASM_COMPILER=clang -DCMAKE_ASM_COMPILER_WORKS=ON -DCMAKE_ASM_COMPILER_TARGET=aarch64-apple-darwin -DCMAKE_C_COMPILER=clang -DCMAKE_C_COMPILER_WORKS=ON -DCMAKE_C_COMPILER_TARGET=aarch64-apple-darwin -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_CXX_COMPILER_WORKS=ON -DCMAKE_CXX_COMPILER_TARGET=aarch64-apple-darwin -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_PROJECTS= -DLLVM_ENABLE_RUNTIMES= -DLLVM_HOST_TRIPLE=aarch64-apple-darwin -DLLVM_INSTALL_UTILS=ON -DLLVM_TARGETS_TO_BUILD=BPF -DLLVM_USE_LINKER=lld
[...]
-- Performing Test LLVM_LIBSTDCXX_MIN
-- Performing Test LLVM_LIBSTDCXX_MIN - Failed
CMake Error at cmake/modules/CheckCompilerVersion.cmake:88 (message):
  libstdc++ version must be at least 7.4.
Call Stack (most recent call first):
  cmake/config-ix.cmake:16 (include)
  CMakeLists.txt:949 (include)


-- Configuring incomplete, errors occurred!
See also "/root/llvm/build/CMakeFiles/CMakeOutput.log".
See also "/root/llvm/build/CMakeFiles/CMakeError.log".

Then I tried an another trick, which is passing -DCMAKE_C(XX)_FLAGS=-fuse-ld=lld, but then it complains about the lack of macOS System library:

root@8167de35cca2:~/llvm# cmake -S llvm -B build -G Ninja -DCMAKE_BUILD_TYPE=Debug -DCMAKE_ASM_COMPILER=clang -DCMAKE_ASM_COMPILER_TARGET=aarch64-apple-darwin -DCMAKE_C_COMPILER=clang -DCMAKE_C_COMPILER_TARGET=aarch64-apple-darwin -DCMAKE_C_FLAGS=-fuse-ld=lld -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_CXX_COMPILER_TARGET=aarch64-apple-darwin -DCMAKE_CXX_FLAGS=-fuse-ld=lld -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_PROJECTS= -DLLVM_ENABLE_RUNTIMES= -DLLVM_HOST_TRIPLE=aarch64-apple-darwin -DLLVM_INSTALL_UTILS=ON -DLLVM_TARGETS_TO_BUILD=BPF -DLLVM_USE_LINKER=lld
[...]
-- Check for working C compiler: /usr/bin/clang
-- Check for working C compiler: /usr/bin/clang - broken
CMake Error at /usr/share/cmake-3.22/Modules/CMakeTestCCompiler.cmake:69 (message):
  The C compiler

    "/usr/bin/clang"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /root/llvm/build/CMakeFiles/CMakeTmp

    Run Build Command(s):/usr/bin/ninja cmTC_e5b80 && [1/2] Building C object CMakeFiles/cmTC_e5b80.dir/testCCompiler.c.o
    clang: warning: argument unused during compilation: '-fuse-ld=lld' [-Wunused-command-line-argument]
    [2/2] Linking C executable cmTC_e5b80
    FAILED: cmTC_e5b80
    : && /usr/bin/clang --target=aarch64-apple-darwin -fuse-ld=lld  CMakeFiles/cmTC_e5b80.dir/testCCompiler.c.o -o cmTC_e5b80   && :
    ld64.lld: error: library not found for -lSystem
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    ninja: build stopped: subcommand failed.

Not sure if the actual LLVM build would complain about lack of -lSystem, but at this point I don't think that the whole gymnastics to make this check work is worth it. Building on macOS runners works fine.

Fair. Thanks for trying -- consider leaving a short comment.

Build LLVM and bpf-linker with statically linked libLLVM for multiple architectures. Include the resulting build artifacts on the release pages, so they can be installed with `cargo binstall`

vadorovsky force-pushed the binstall branch 2 times, most recently from c362c1e to 42e16f3 Compare August 2, 2024 15:50

tamird reviewed Aug 2, 2024

View reviewed changes

.github/workflows/release.yml Show resolved Hide resolved

.github/workflows/release.yml Outdated Show resolved Hide resolved

.github/workflows/ci.yml Outdated Show resolved Hide resolved

vadorovsky force-pushed the binstall branch 5 times, most recently from 7a507e8 to 72afe24 Compare August 14, 2024 15:54

tamird reviewed Aug 14, 2024

View reviewed changes

vadorovsky force-pushed the binstall branch 10 times, most recently from fbb5e3a to 2b3fc8b Compare August 14, 2024 17:11

tamird reviewed Aug 14, 2024

View reviewed changes

.github/workflows/llvm.yml Outdated Show resolved Hide resolved

.github/workflows/llvm.yml Outdated Show resolved Hide resolved

.github/workflows/llvm.yml Outdated Show resolved Hide resolved

vadorovsky force-pushed the binstall branch 10 times, most recently from 35354c9 to 5615015 Compare August 18, 2024 06:00

vadorovsky force-pushed the binstall branch 12 times, most recently from 7e42e98 to 09141cb Compare September 26, 2024 08:10

vadorovsky mentioned this pull request Sep 26, 2024

ci: Update kernel images, run local integration tests #229

Closed

vadorovsky force-pushed the binstall branch 5 times, most recently from 067b453 to 429f90e Compare September 27, 2024 12:54

tamird reviewed Sep 27, 2024

View reviewed changes

vadorovsky commented Sep 27, 2024

View reviewed changes

tamird reviewed Sep 27, 2024

View reviewed changes

vadorovsky commented Sep 28, 2024

View reviewed changes

tamird reviewed Sep 28, 2024

View reviewed changes

vadorovsky force-pushed the binstall branch from ac0e598 to b64769d Compare October 7, 2024 09:31

ci: Build statically linked bpf-linker in CI

07163e3

Build LLVM and bpf-linker with statically linked libLLVM for multiple architectures. Include the resulting build artifacts on the release pages, so they can be installed with `cargo binstall`

vadorovsky force-pushed the binstall branch from b64769d to 07163e3 Compare October 14, 2024 09:46

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ci: Build statically linked bpf-linker in CI #215

ci: Build statically linked bpf-linker in CI #215

vadorovsky commented Aug 2, 2024 •

edited

Loading

tamird left a comment

vadorovsky left a comment

vadorovsky left a comment

vadorovsky left a comment

tamird left a comment

vadorovsky left a comment

tamird left a comment

ci: Build statically linked bpf-linker in CI #215

Are you sure you want to change the base?

ci: Build statically linked bpf-linker in CI #215

Conversation

vadorovsky commented Aug 2, 2024 • edited Loading

tamird left a comment

Choose a reason for hiding this comment

vadorovsky left a comment

Choose a reason for hiding this comment

vadorovsky left a comment

Choose a reason for hiding this comment

vadorovsky left a comment

Choose a reason for hiding this comment

tamird left a comment

Choose a reason for hiding this comment

vadorovsky left a comment

Choose a reason for hiding this comment

tamird left a comment

Choose a reason for hiding this comment

vadorovsky commented Aug 2, 2024 •

edited

Loading