libbpf / libbpf-sys Goto Github PK

View Code? Open in Web Editor NEW

188.0 8.0 46.0 176 KB

Rust bindings to libbpf from the Linux kernel

Home Page: https://crates.io/crates/libbpf-sys/

License: BSD 2-Clause "Simplified" License

Rust 99.54% Shell 0.32% C 0.14%

bpf ebpf xdp linux rust

libbpf-sys's Introduction

libbpf-sys

Rust bindings to libbpf from the Linux kernel

Maintainer: Alex Forster <[email protected]>
License: BSD-2-Clause

libbpf-sys is the packaged result of using bindgen to automatically generate Rust FFI bindings to libbpf from the Linux kernel.

Warning: this crate does not provide a high-level or "safe" API wrapper around libbpf. If you are looking for an easier way to use libbpf, check out these other crates that implement higher-level APIs using libbpf-sys...

afxdp: a Rust interface for AF_XDP – GitHub | Crates.io
libbpf-cargo: Cargo plugin to build bpf programs – GitHub | Crates.io
libbpf-rs: a safe, idiomatic, and opinionated wrapper around libbpf-sys – GitHub | Crates.io
rebpf: write and load eBPF programs in Rust – GitHub | Crates.io
xsk-rs: a Rust interface for Linux AF_XDP sockets – Github | Crates.io

The community is encouraged to build higher-level crates using libbpf-sys. Please let me know if you do!

Building

As part of the cargo build process, an included copy of libbpf is compiled and statically linked into the resulting binary. This means that, in order to build a project that depends on this crate, your system must provide a working C compiler toolchain (GCC and Clang should both work). Additionally, your system must provide development headers for zlib and libelf, and they must be discoverable via pkgconfig.

Building on a fresh Debian/Ubuntu installation:

$ apt-get install git rustc cargo build-essential pkgconf zlib1g-dev libelf-dev
$ git clone --recurse-submodules https://github.com/libbpf/libbpf-sys.git && cd libbpf-sys
$ cargo build

Building on a fresh RHEL/Fedora installation:

$ yum install git rust cargo gcc make pkgconf zlib-devel elfutils-libelf-devel
$ git clone --recurse-submodules https://github.com/libbpf/libbpf-sys.git && cd libbpf-sys
$ cargo build

Environment Variables

LIBBPF_SYS_EXTRA_CFLAGS can be used to pass extra cflags when vendoring libbpf, libz or libelf.
LIBBPF_SYS_LIBRARY_PATH: colon separated paths for the linker to find native libs.

Distribution

When you add this crate as a dependency to your project, your resulting binaries will dynamically link with libz and libelf. This means that the systems where you run your binaries must have these libraries installed.

Versioning

Because the API of this crate is automatically generated from libbpf sources, it uses a versioning scheme based on the version of libbpf that it provides.

The "Major.Minor" semver numbers correspond exactly to the libbpf version that each release provides. For example, the 0.6.x releases of this crate provides the API for the libbpf v0.6.x releases.

In order to allow for human error, the "Patch" semver number is used by this crate and does not necessarily match the provided libbpf version. For example, both the 0.6.1 and 0.6.2 releases of this crate contain bindings to libbpf v0.6.1, but the later release contains bugfixes and/or enhancements to the crate itself.

The exact version of libbpf that is provided by any given release can be found in the "Build Metadata" semver section, which comes after the + in the version string. For example, 0.6.2+v0.6.1 indicates that the crate version is 0.6.2 and the upstream libbpf version is v0.6.1.

Licensing and Dependencies

This crate is released under the BSD 2-Clause license, and is careful to avoid infecting users with viral licenses.

It currently depends on the following third-party libraries:

	Website	License	Linkage
libbpf	github.com/libbpf/libbpf	`LGPL-2.1-only OR BSD-2-Clause`	Static
libelf	sourceware.org/elfutils	`LGPL-2.1-or-later OR LGPL-3.0-or-later`	Dynamic
zlib	zlib.net	`Zlib`	Dynamic

libbpf-sys's People

Contributors

Stargazers

Watchers

Forkers

aterlo uccidibuti danobi alexeldeib ghglavan tchebb gdetal ujang360 laarmen willfindlay chenhengqi chris-morgan benfogle anakryiko arilou kriomant kckeiks pinkforest chengshuyi mdaverde honsunrise bpfdeploy-io germancoding vlrpl javierhonduco isabella232 fanweixiao shaneutt danielocfb dschatzberg saschagrunert 0xb10c krallin ilink mmullin-halcyon hi-glenn syogaraj ehfive forkgull jfernandez arloor lu-zero editso shabbirhasan1 kxxt

libbpf-sys's Issues

Consider using system-deps

It should make easier to find the host libraries.

could not find native static library elf, perhaps an -L flag is missing? (using static feature)

Original Issue: libbpf/libbpf-rs#515

Cannot build the project using the static feature.

Cargo.toml

[...]
libbpf-rs = { version = "0.21.1", features = ["static"] }
[...]

Error:

error: could not find native static library `elf`, perhaps an -L flag is missing?

error: could not compile `libbpf-sys` (lib) due to previous error

Caused by:
  process didn't exit successfully: `CARGO=/home/akshat/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/cargo CARGO_CRATE_NAME=libbpf_sys CARGO_MANIFEST_DIR=/home/akshat/.cargo/registry/src/index.crates.io-6f17d22bba15001f/libbpf-sys-1.2.1+v1.2.0 CARGO_PKG_AUTHORS='Alex Forster <[email protected]>:Dan Siemon <[email protected]>:Daniel Xu <[email protected]>' CARGO_PKG_DESCRIPTION='Rust bindings to libbpf from the Linux kernel' CARGO_PKG_HOMEPAGE='https://github.com/libbpf/libbpf-sys' CARGO_PKG_LICENSE=BSD-2-Clause CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=libbpf-sys CARGO_PKG_README=README.md CARGO_PKG_REPOSITORY='https://github.com/libbpf/libbpf-sys' CARGO_PKG_RUST_VERSION='' CARGO_PKG_VERSION=1.2.1+v1.2.0 CARGO_PKG_VERSION_MAJOR=1 CARGO_PKG_VERSION_MINOR=2 CARGO_PKG_VERSION_PATCH=1 CARGO_PKG_VERSION_PRE='' LD_LIBRARY_PATH='/home/akshat/wrkspc/ebpf-collector/target/debug/deps:/home/akshat/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib:/home/akshat/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib' OUT_DIR=/home/akshat/wrkspc/ebpf-collector/target/debug/build/libbpf-sys-c0bc7f46411bb923/out /home/akshat/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustc --crate-name libbpf_sys --edition=2018 /home/akshat/.cargo/registry/src/index.crates.io-6f17d22bba15001f/libbpf-sys-1.2.1+v1.2.0/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=145 --crate-type lib --crate-type staticlib --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 --cfg 'feature="static"' -C metadata=d2ad6cf3be166f7b -C extra-filename=-d2ad6cf3be166f7b --out-dir /home/akshat/wrkspc/ebpf-collector/target/debug/deps -L dependency=/home/akshat/wrkspc/ebpf-collector/target/debug/deps --cap-lints warn -L native=/home/akshat/wrkspc/ebpf-collector/target/debug/build/libbpf-sys-c0bc7f46411bb923/out -L native=/home/akshat/wrkspc/ebpf-collector/target/debug/deps -L native=/home/akshat/wrkspc/ebpf-collector/target/debug -L native=/home/akshat/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib -L native=/home/akshat/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib -l static=elf -l static=z -l static=bpf` (exit status: 1)

struct perf_event_attr seems to be wrong

Hi,

Looking at the definition of perf_event_attr it seems wrong compared to what it should be
#[repr(C)] #[derive(Debug, Default, Copy, Clone)] pub struct perf_event_attr { pub _address: u8, }

Where in fact it's

           struct perf_event_attr {
               __u32 type;                 /* Type of event */
               __u32 size;                 /* Size of attribute structure */
               __u64 config;               /* Type-specific configuration */

               union {
                   __u64 sample_period;    /* Period of sampling */
                   __u64 sample_freq;      /* Frequency of sampling */
               };

               __u64 sample_type;  /* Specifies values included in sample */
               __u64 read_format;  /* Specifies values returned in read */

               __u64 disabled       : 1,   /* off by default */
                     inherit        : 1,   /* children inherit it */
                     pinned         : 1,   /* must always be on PMU */
                     exclusive      : 1,   /* only group on PMU */
                     exclude_user   : 1,   /* don't count user */
                     exclude_kernel : 1,   /* don't count kernel */
                     exclude_hv     : 1,   /* don't count hypervisor */
                     exclude_idle   : 1,   /* don't count when idle */
                     mmap           : 1,   /* include mmap data */
                     comm           : 1,   /* include comm data */
                     freq           : 1,   /* use freq, not period */
                     inherit_stat   : 1,   /* per task counts */
                     enable_on_exec : 1,   /* next exec enables */
                     task           : 1,   /* trace fork/exit */
                     watermark      : 1,   /* wakeup_watermark */
                     precise_ip     : 2,   /* skid constraint */
                     mmap_data      : 1,   /* non-exec mmap data */
                     sample_id_all  : 1,   /* sample_type all events */
                     exclude_host   : 1,   /* don't count in host */
                     exclude_guest  : 1,   /* don't count in guest */
                     exclude_callchain_kernel : 1,
                                           /* exclude kernel callchains */
                     exclude_callchain_user   : 1,
                                           /* exclude user callchains */
                     mmap2          :  1,  /* include mmap with inode data */
                     comm_exec      :  1,  /* flag comm events that are
                                              due to exec */
                     use_clockid    :  1,  /* use clockid for time fields */
                     context_switch :  1,  /* context switch data */
                     write_backward :  1,  /* Write ring buffer from end
                                              to beginning */
                     namespaces     :  1,  /* include namespaces data */
                     ksymbol        :  1,  /* include ksymbol events */
                     bpf_event      :  1,  /* include bpf events */
                     aux_output     :  1,  /* generate AUX records
                                              instead of events */
                     cgroup         :  1,  /* include cgroup events */
                     text_poke      :  1,  /* include text poke events */

                     __reserved_1   : 30;

               union {
                   __u32 wakeup_events;    /* wakeup every n events */
                   __u32 wakeup_watermark; /* bytes before wakeup */
               };

               __u32     bp_type;          /* breakpoint type */

               union {
                   __u64 bp_addr;          /* breakpoint address */
                   __u64 kprobe_func;      /* for perf_kprobe */
                   __u64 uprobe_path;      /* for perf_uprobe */
                   __u64 config1;          /* extension of config */
               };

               union {
                   __u64 bp_len;           /* breakpoint length */
                   __u64 kprobe_addr;      /* with kprobe_func == NULL */
                   __u64 probe_offset;     /* for perf_[k,u]probe */
                   __u64 config2;          /* extension of config1 */
               };
               __u64 branch_sample_type;   /* enum perf_branch_sample_type */
               __u64 sample_regs_user;     /* user regs to dump on samples */
               __u32 sample_stack_user;    /* size of stack to dump on
                                              samples */
               __s32 clockid;              /* clock to use for time fields */
               __u64 sample_regs_intr;     /* regs to dump on samples */
               __u32 aux_watermark;        /* aux bytes before wakeup */
               __u16 sample_max_stack;     /* max frames in callchain */
               __u16 __reserved_2;         /* align to u64 */

           };

bpf_tc_opts should use the MaybeUninit method of creating a default

Similar to bpf_tc_hook, struct bpf_tc_opts needs to be fully zeroed or the BPF verifier will complain "libbpf: bpf_tc_opts has non-zero extra bytes"

client code can do this work, but it would be nice if the libbpf-sys library did it for the clients

Question: How does rust-bindgen determine that bpf_tc_hooks needs a MaybeUninit zero method, while bpf_tc_opts does not?

Test that `libbpf-rs` compiles without error in CI

Right now, there are no tests beyond ensuring that libbpf_set_print can be called. This ensures that something hasn't gone horribly wrong, but it doesn't do much to prevent API breakage.

In libbpf/libbpf-rs#303, a minor release of libbpf-sys broke libbpf-rs because bindgen's default behavior changed. This would have been prevented if we somehow tested compiling libbpf-rs in CI, but I don't know enough about GitHub CI to implement that.

libbpf-sys fails to build if there are spaces in the directory path.

Any spaces in cwd causes a Makefile to mess things up.

docs.rs build fails

https://docs.rs/crate/libbpf-sys/0.0.6-5/builds

32 bit build broken?

In response to libbpf/libbpf-rs#500 I created danielocfb@5e93a20 to make sure that libbpf-sys is also tested in a 32 bit setting. That seems to blow up pretty prominently immediately: https://github.com/danielocfb/libbpf-sys/actions/runs/5479871661/jobs/9982296567

--> src/bindings.rs:512:49
    |
512 | pub const PERF_TXN_ABORT_MASK: _bindgen_ty_52 = 18446744069414584320;
    |                                                 ^^^^^^^^^^^^^^^^^^^^
    |
    = note: the literal `18446744069414584320` does not fit into the type `u32` whose range is `0..=4294967295`
    = note: `#[deny(overflowing_literals)]` on by default

error: literal out of range for `u32`
    --> src/bindings.rs:1478:53
     |
1478 | pub const PERF_CONTEXT_HV: perf_callchain_context = 18446744073709551584;
     |                                                     ^^^^^^^^^^^^^^^^^^^^
     |
     = note: the literal `18446744073709551584` does not fit into the type `u32` whose range is `0..=4294967295`

error: literal out of range for `u32`
    --> src/bindings.rs:1479:57
     |
1479 | pub const PERF_CONTEXT_KERNEL: perf_callchain_context = 18446744073709551488;
     |                                                         ^^^^^^^^^^^^^^^^^^^^
     |
     = note: the literal `18446744073709551488` does not fit into the type `u32` whose range is `0..=4294967295`

error: literal out of range for `u32`
    --> src/bindings.rs:1480:55
     |
1480 | pub const PERF_CONTEXT_USER: perf_callchain_context = 18446744073709551104;
     |                                                       ^^^^^^^^^^^^^^^^^^^^
     |
     = note: the literal `18446744073709551104` does not fit into the type `u32` whose range is `0..=4294967295`

error: literal out of range for `u32`
    --> src/bindings.rs:1481:56
     |
1481 | pub const PERF_CONTEXT_GUEST: perf_callchain_context = 18446744073709549568;
     |                                                        ^^^^^^^^^^^^^^^^^^^^
     |
     = note: the literal `18446744073709549568` does not fit into the type `u32` whose range is `0..=4294967295`

error: literal out of range for `u32`
    --> src/bindings.rs:1482:63
     |
1482 | pub const PERF_CONTEXT_GUEST_KERNEL: perf_callchain_context = 18446744073709549440;
     |                                                               ^^^^^^^^^^^^^^^^^^^^
     |
     = note: the literal `18446744073709549440` does not fit into the type `u32` whose range is `0..=4294967295`

error: literal out of range for `u32`
    --> src/bindings.rs:1483:61
     |
1483 | pub const PERF_CONTEXT_GUEST_USER: perf_callchain_context = 18446744073709549056;
     |                                                             ^^^^^^^^^^^^^^^^^^^^
     |
     = note: the literal `18446744073709549056` does not fit into the type `u32` whose range is `0..=4294967295`

error: literal out of range for `u32`
    --> src/bindings.rs:1484:54
     |
1484 | pub const PERF_CONTEXT_MAX: perf_callchain_context = 18446744073709547521;
     |                                                      ^^^^^^^^^^^^^^^^^^^^
     |
     = note: the literal `18446744073709547521` does not fit into the type `u32` whose range is `0..=4294967295`

error: literal out of range for `u32`
    --> src/bindings.rs:2908:47
     |
2908 | pub const BPF_F_CTXLEN_MASK: _bindgen_ty_65 = 4503[59](https://github.com/danielocfb/libbpf-sys/actions/runs/5479871661/jobs/9982296567#step:8:60)5332403200;
     |                                               ^^^^^^^^^^^^^^^^
     |
     = note: the literal `4503595332403200` does not fit into the type `u32` whose range is `0..=4294967295`

error: could not compile `libbpf-sys` (lib) due to 9 previous errors

Any idea how we can adjust the type of those constants, by any chance? I haven't found any knobs.

Build script panics cause confusion

The build script wasn't written in a very user-friendly manner. Let's make it fail more gracefully.

Crate versioning scheme requires all dependencies to use exactly same libbpf-sys version

I want to use both redbpf crate to load BPF programs and xsk-rs to handle packets on user-space side. I even initiated moving redbpf crate from using it's own libbpf bindings to using libbpf-sys. But now I still have a problem: redpbf and xsk-rs use different versions of libbpf-sys: ^0.6.1-2 and ^0.6.0-1 respectively.
Usually '^version' notation lets Cargo to choose newer version for both, but prerelease suffix, if I understand correctly, prevents it.

So, how can I use several crates depending on libbpf-sys? Requiring all of dependant crates to use exactly same version of libbpf-sys doesn't seem like a solution, any future update of any of crates will break my build.

Build fails with file not found error panic

Trying to compile libbpf-sys 0.4.0-2 on Ubuntu 21.04. Here is a skeleton Cargo.toml that illustrates the issue on my system:

[package]
name = "foo"
version = "0.1.0"
edition = "2018"

[dependencies]
libbpf-sys = { version = "0.4.0-2" }

cargo build trace with RUST_BACKTRACE=1:

   Compiling libbpf-sys v0.4.0-2
error: failed to run custom build command for `libbpf-sys v0.4.0-2`

Caused by:
  process didn't exit successfully: `/tmp/foo/target/debug/build/libbpf-sys-fa6170e7fd760d00/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', /home/cody/.cargo/registry/src/github.com-1ecc6299db9ec823/libbpf-sys-0.4.0-2/build.rs:44:14
  stack backtrace:
     0: rust_begin_unwind
               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/panicking.rs:515:5
     1: core::panicking::panic_fmt
               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/core/src/panicking.rs:92:14
     2: core::result::unwrap_failed
               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/core/src/result.rs:1355:5
     3: core::result::Result<T,E>::unwrap
               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/core/src/result.rs:1037:23
     4: build_script_build::main
               at ./build.rs:34:22
     5: core::ops::function::FnOnce::call_once
               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/core/src/ops/function.rs:227:5
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

zlib and libelf dependencies on my system:

pkg-config --modversion zlib
1.2.11
pkg-config --modversion libelf
0.183

Let me know if I can provide any more information that could be used to reproduce. Resolving #20 might give a better picture

Add a feature to statically link elfutils and zlib

👋 Hi folks! First of all, thanks so much for this crate!

I am trying to create a statically linked binary, rbperf, that depends on libbpf-rs.

The first thing I bumped into was that while libbpf is linked statically, elfutils and zlib aren't. With this patch to add this feature in libbpf-sys (javierhonduco@4a6b367) and exposing it in libbpf-rs (javierhonduco/libbpf-rs@b66a96e) I am able to depend on fewer dynamic libraries, and getting a bit closer to the fully static goal.

Before

[javierhonduco@computer-2 rbperf]$ ldd target/debug/rbperf
	linux-vdso.so.1 (0x00007ffca76d3000)
	libelf.so.1 => /lib/libelf.so.1 (0x00007fbfb7f5a000)
	libz.so.1 => /lib64/libz.so.1 (0x00007fbfb7f40000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fbfb7f20000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fbfb7e42000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fbfb7c41000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fbfb87cf000)

After

[javierhonduco@computer rbperf]$ ldd target/debug/rbperf
	linux-vdso.so.1 (0x00007ffde392c000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f6dd42ff000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f6dd4221000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f6dd4020000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f6dd4ba0000)

Would you be open to the idea of having this implemented? If so, I would be more than happy to open a PR 😄

Could not find native static library elf, perhaps an -L flag is missing? (using static feature)

cargo build -v --features static

Output:

       Fresh cfg_aliases v0.1.1
       Fresh libc v0.2.154
       Fresh cfg-if v1.0.0
       Fresh bitflags v2.5.0
       Fresh pkg-config v0.3.30
       Fresh cc v1.0.97
       Fresh nix v0.28.0
   Compiling libbpf-sys v1.4.1+v1.4.0 (/home/kes/libbpf-sys)
     Running `rustc --crate-name libbpf_sys --edition=2018 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=104 --crate-type lib --crate-type staticlib --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 --cfg 'feature="default"' --cfg 'feature="static"' --cfg 'feature="static-libbpf"' --cfg 'feature="static-libelf"' --cfg 'feature="static-zlib"' --cfg 'feature="vendored-libbpf"' -C metadata=e8b69177a174d00c -C extra-filename=-e8b69177a174d00c --out-dir /home/kes/libbpf-sys/target/debug/deps -C incremental=/home/kes/libbpf-sys/target/debug/incremental -L dependency=/home/kes/libbpf-sys/target/debug/deps -L native=/home/kes/libbpf-sys/target/debug/build/libbpf-sys-ac808a735e3172a4/out -L native=/home/kes/libbpf-sys/target/debug/deps -L native=/home/kes/libbpf-sys/target/debug -L native=/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib -l static=elf -l static=z -l static=bpf`
error: could not find native static library `elf`, perhaps an -L flag is missing?

error: could not compile `libbpf-sys` (lib) due to 1 previous error

Caused by:
  process didn't exit successfully: `rustc --crate-name libbpf_sys --edition=2018 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=104 --crate-type lib --crate-type staticlib --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 --cfg 'feature="default"' --cfg 'feature="static"' --cfg 'feature="static-libbpf"' --cfg 'feature="static-libelf"' --cfg 'feature="static-zlib"' --cfg 'feature="vendored-libbpf"' -C metadata=e8b69177a174d00c -C extra-filename=-e8b69177a174d00c --out-dir /home/kes/libbpf-sys/target/debug/deps -C incremental=/home/kes/libbpf-sys/target/debug/incremental -L dependency=/home/kes/libbpf-sys/target/debug/deps -L native=/home/kes/libbpf-sys/target/debug/build/libbpf-sys-ac808a735e3172a4/out -L native=/home/kes/libbpf-sys/target/debug/deps -L native=/home/kes/libbpf-sys/target/debug -L native=/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib -l static=elf -l static=z -l static=bpf` (exit status: 1)

Environment

OS: Arch Linux x86_64
Kernel: 6.8.9-arch1-2

0.6.1-1 can't be built with rebuild.sh

$ ./rebuild.sh
[+] Building 251.3s (9/9) FINISHED
 => [internal] load build definition from Dockerfile                                                                    0.0s
 => => transferring dockerfile: 1.57kB                                                                                  0.0s
 => [internal] load .dockerignore                                                                                       0.0s
 => => transferring context: 2B                                                                                         0.0s
 => [internal] load metadata for docker.io/amd64/ubuntu:focal                                                           3.0s
 => [1/5] FROM docker.io/amd64/ubuntu:focal@sha256:57df66b9fc9ce2947e434b4aa02dbe16f6685e20db0c170917d4a1962a5fe6a9     4.7s
 => => resolve docker.io/amd64/ubuntu:focal@sha256:57df66b9fc9ce2947e434b4aa02dbe16f6685e20db0c170917d4a1962a5fe6a9     0.0s
 => => sha256:ea362f368469f909a95f9a6e54ebe0121ce0a8e3c30583dd9c5fb35b14544dec 28.57MB / 28.57MB                        3.3s
 => => sha256:57df66b9fc9ce2947e434b4aa02dbe16f6685e20db0c170917d4a1962a5fe6a9 529B / 529B                              0.0s
 => => sha256:d13c942271d66cb0954c3ba93e143cd253421fe0772b8bed32c4c0077a546d4d 1.46kB / 1.46kB                          0.0s
 => => extracting sha256:ea362f368469f909a95f9a6e54ebe0121ce0a8e3c30583dd9c5fb35b14544dec                               1.2s
 => [2/5] WORKDIR /usr/local/src/libbpf-sys                                                                             0.1s
 => [3/5] RUN  export DEBIAN_FRONTEND=noninteractive;  apt-get -q update;  apt-get -q install -y curl build-essential  65.6s
 => [4/5] RUN  curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y --default-toolchain stable;     29.7s
 => [5/5] RUN  source $HOME/.cargo/env;  cargo install --git https://github.com/rust-lang/rust-bindgen --rev 2aed6b0  141.1s
 => exporting to image                                                                                                  7.0s
 => => exporting layers                                                                                                 7.0s
 => => writing image sha256:c69eaacaaeedab7597f5bee00acbaa5991961d174fc9a9f7179aec0cfb30a698                            0.0s
 => => naming to docker.io/library/libbpf-sys-builder                                                                   0.0s

Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them
/usr/local/src/libbpf-sys/bindings.h:8:10: fatal error: 'libbpf/include/uapi/linux/if_link.h' file not found
/usr/local/src/libbpf-sys/bindings.h:8:10: fatal error: 'libbpf/include/uapi/linux/if_link.h' file not found, err: true
thread 'main' panicked at 'Unable to generate bindings: ()', src/main.rs:52:36
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Bindgen unexpectedly panicked
This may be caused by one of the known-unsupported things (https://rust-lang.github.io/rust-bindgen/cpp.html), please modify the bindgen flags to work around it as described in https://rust-lang.github.io/rust-bindgen/cpp.html
Otherwise, please file an issue at https://github.com/rust-lang/rust-bindgen/issues/new

Build error

version: 0.5.0-2

error[E0063]: missing fields `__bindgen_padding_0` and `__bindgen_padding_1` in initializer of `bpf_object_open_opts`
  --> src/bpf/object.rs:41:9
   |
41 |         libbpf_sys::bpf_object_open_opts {
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `__bindgen_padding_0` and `__bindgen_padding_1`

For more information about this error, try `rustc --explain E0063`.

why are these paddings explicit? it is a breaking change that makes CI broken. please consider using another versioning scheme to avoid this kind of problems.

Clarification on the metadata in semvar version

Hi, I want to ask about the metadata in the semvar version since it produces the warning:

version requirement 1.1.1+v1.0.1 for dependency libbpf-sys includes semver metadata which will be ignored, removing the metadata is recommended to avoid confusion

If I understand this correctly, the +v1.0.1 is for information only to indicate to a human reader which libbpf version is used from upstream. Therefore, if needed, we can safely remove the metadata version from cargo manifest?

Will you consider supporting it on Android?

Hi, I tried to build for Android, but the build failed. Does it support Android? If possible, can I create a PR to support it?

Incorrect libbpf submodule published to crates.io for version 1.0.2+v1.0.1

The version of libbpf published to crates.io is version 1.0.0 not 1.0.1

Steps to reproduce:
$ mkdir download_area
$ cd download_area
$ curl -L https://crates.io/api/v1/crates/libbpf-sys/1.0.2+v1.0.1/download --output libbpf-sys.tar.gz
$ tar xzvf libbpf-sys.tar.gz
$ cat libbpf-sys-1.0.2+v1.0.1/libbpf/src/Makefile | grep LIBBPF_PATCH_VERSION

Expected Result:
LIBBPF_PATCH_VERSION := 1

Actual Result
LIBBPF_PATCH_VERSION := 0

NOTES:

Observe that in libbpf.h the change described here: libbpf/libbpf@5847387
is not available.

Because libbpf is at version 1.0.0, but the bindings.rs was generated for version 1.0.1 the bpf_object_open_opts structure is incorrect.

AArch64 support broken?

With redbpf, we recently started migrating to libbpf-sys from our own wrapper that preceded this project. However, our CI quickly flagged up an error on aarch64, which I think we can only address by partially reverting to generating our own bindings to certain calls.

My question is whether we're mis-using libbpf-sys, or is this a known limitation? I couldn't find other than AMD64 compatibility in the CI.

I'd be happy to dig deeper on this, just wanted to get a confirmation if you have any experience on this front.

Thanks!

Possibility to build/link with non-system & non-vendored libbpf?

This came up internally. Folks were wondering if it's possible to build & link with a "custom" libbpf, anywhere on the file system. If not it may be useful to add that capability down the line.

Show example to build

Recently, I was trying out building libbpf-rs ran into libbpf/libbpf-rs#300

I think it would be nice to show which system packages need to be installed, e.g. on Ubuntu

sudo apt install libelf-dev pkgconf

where pkgconf provides pkg-config executable.

Cross-compilation is broken

libbpf-sys cannot be cross-compiled.

default-features

There's no way to specify include path for cross-compilation. I opened #93 to fix it.

cargo build --target aarch64-unknown-linux-gnu 
  In file included from bpf_prog_linfo.c:9:
  libbpf_internal.h:19:10: fatal error: libelf.h: No such file or directory
     19 | #include <libelf.h>
        |          ^~~~~~~~~~
  compilation terminated.
  In file included from nlattr.c:14:
  libbpf_internal.h:19:10: fatal error: libelf.h: No such file or directory
     19 | #include <libelf.h>
        |          ^~~~~~~~~~
  compilation terminated.
  In file included from libbpf_errno.c:15:
  libbpf_internal.h:19:10: fatal error: libelf.h: No such file or directory
     19 | #include <libelf.h>
        |          ^~~~~~~~~~
  compilation terminated.
  make: *** [Makefile:134: /home/kxxt/repos/libbpf-sys/target/aarch64-unknown-linux-gnu/debug/build/libbpf-sys-099efd81f8db105f/out/obj/staticobjs/nlattr.o] Error 1
  make: *** Waiting for unfinished jobs....
  make: *** [Makefile:134: /home/kxxt/repos/libbpf-sys/target/aarch64-unknown-linux-gnu/debug/build/libbpf-sys-099efd81f8db105f/out/obj/staticobjs/bpf_prog_linfo.o] Error 1
  make: *** [Makefile:134: /home/kxxt/repos/libbpf-sys/target/aarch64-unknown-linux-gnu/debug/build/libbpf-sys-099efd81f8db105f/out/obj/staticobjs/libbpf_errno.o] Error 1
  btf.c:18:10: fatal error: gelf.h: No such file or directory
     18 | #include <gelf.h>
        |          ^~~~~~~~
  compilation terminated.

static, vendored

cargo build --target aarch64-unknown-linux-gnu -F static,vendored

  Makefile.am: installing './INSTALL'
  backends/Makefile.am: installing 'config/depcomp'
  configure.ac: installing 'config/ylwrap'
  parallel-tests: installing 'config/test-driver'
  configure: error: in '/home/kxxt/repos/libbpf-sys/elfutils':
  configure: error: cannot run C compiled programs.
  If you meant to cross compile, use '--host'.
  See 'config.log' for more details
  thread 'main' panicked at build.rs:305:5:
  make failed
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

After I modify build.rs to pass --host aarch64-linux-gnu to configure, another error:

  --- stderr
  configure: WARNING: not running biarch tests,  does not work
  /home/kxxt/repos/libbpf-sys/elfutils/libcpu/i386_parse.y:243.1-8: warning: POSIX Yacc does not support %defines [-Wyacc]
    243 | %defines
        | ^~~~~~~~
  /bin/sh: line 1: ./i386_gendis: cannot execute binary file: Exec format error
  /bin/sh: line 1: ./i386_gendis: cannot execute binary file: Exec format error
  make[1]: *** [Makefile:814: i386_dis.h] Error 126
  make[1]: *** Waiting for unfinished jobs....
  make[1]: *** [Makefile:814: x86_64_dis.h] Error 126
  make: *** [Makefile:542: install-recursive] Error 1
  thread 'main' panicked at build.rs:318:5:
  make failed
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

This is an upstream bug(https://sourceware.org/bugzilla/show_bug.cgi?id=28891). Unfortunately, to fix it, we need to import upstream provided release tarballs into this repo instead of using git submodule. Is that acceptable?

Missing libbpf v0.2 symbols

I'm getting linker errors when I use the v0.2 libbpf-sys from crates.io:

  = note: /bin/ld: /home/daniel/dev/libbpf-rs/target/debug/deps/cargo_libbpf-e1881abc62d2e476.3pzy2gabm1c6gb6f.rcgu.o: in function `cargo_libbpf::btf::btf::Btf::new':
          /home/daniel/dev/libbpf-rs/libbpf-cargo/src/btf/btf.rs:61: undefined reference to `btf__set_endianness'
          collect2: error: ld returned 1 exit status

I don't get the error when I use a local checkout of libbpf-sys:

$ cat Cargo.toml
[...]

[dependencies]
libbpf-sys = { path = "/home/daniel/dev/libbpf-sys" }

$  nm ./target/debug/build/libbpf-sys-37d4aafae3a38032/out/libbpf.a | rg endian
00000000000016c0 T btf__endianness
00000000000016d0 T btf__set_endianness

Since I don't see any special git submodule initialization in the build script, I wonder if the libbpf sources uploaded to crates.io are just whatever you have checked out at time of cargo publish.

If that's the case, if it possible you didn't update the libbpf submodule before cargo publishing? Just a guess.

No support for 32-bit?

The new explicit padding is explicit for 64bit data alignment. Can eBPF used on 32bit machines?

I'm sorry, but I do not have a 32 bit machine to verify whether this is an issue or not.

libbpf vendoring

So libbpf source is currently vendored. And at libbpf-sys build time, cargo builds libbpf, builds shim for the inline functions, builds libbpf-sys rust bits, then links it all together.

I'm wondering why/if libbpf needs to be vendored. IIUC some *-sys libraries link against the system installed library (eg ncurses https://github.com/jeaye/ncurses-rs/blob/master/build.rs#L11).

The reason I bring this up is b/c I noticed that building CO-RE bpf programs requires libbpf headers so you'll need to install libbpf-devel anyways. And then you get some skew between libbpf-devel and libbpf-sys-built libbpf.

Failed to link statically with `-C target-feature=+crt-static` and `--target`

I'm working on an experimental ebpf implementation in conmon-rs, a container runtime monitor written in Rust: containers/conmon-rs#926

I'm not able to link the application statically anymore when using libbpf-rs, which directly depends on libbpf-sys, because of the error:

Running `rustc --crate-name libbpf_sys --edition=2018 /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/libbpf-sys-1.0.4+v1.0.1/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --crate-type staticlib --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 -C debug-assertions=off --cfg 'feature="static"' -C metadata=a3f0ad521523a73e -C extra-filename=-a3f0ad521523a73e --out-dir /home/runner/work/conmon-rs/conmon-rs/target/release/deps -L dependency=/home/runner/work/conmon-rs/conmon-rs/target/release/deps --cap-lints allow -L native=/home/runner/work/conmon-rs/conmon-rs/target/release/build/libbpf-sys-a01c0f94146cf298/out -l static=elf -l static=z -l static=bpf`

error: could not find native static library `elf`, perhaps an -L flag is missing?

error: could not compile `libbpf-sys` due to previous error

Caused by:
  process didn't exit successfully: `rustc --crate-name libbpf_sys --edition=2018 /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/libbpf-sys-1.0.4+v1.0.1/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --crate-type staticlib --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 -C debug-assertions=off --cfg 'feature="static"' -C metadata=a3f0ad521523a73e -C extra-filename=-a3f0ad521523a73e --out-dir /home/runner/work/conmon-rs/conmon-rs/target/release/deps -L dependency=/home/runner/work/conmon-rs/conmon-rs/target/release/deps --cap-lints allow -L native=/home/runner/work/conmon-rs/conmon-rs/target/release/build/libbpf-sys-a01c0f94146cf298/out -l static=elf -l static=z -l static=bpf` (exit status: 1)

It looks like that the RUSTFLAGS are being reset for this crate, but for others they got passed correctly, for example when looking into the build logs:

Running `rustc --crate-name clap --edition=2021 /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-3.2.22/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=z -C linker-plugin-lto -C codegen-units=1 -C debuginfo=2 --cfg 'feature="atty"' --cfg 'feature="cargo"' --cfg 'feature="clap_derive"' --cfg 'feature="color"' --cfg 'feature="default"' --cfg 'feature="deprecated"' --cfg 'feature="derive"' --cfg 'feature="env"' --cfg 'feature="once_cell"' --cfg 'feature="std"' --cfg 'feature="strsim"' --cfg 'feature="suggestions"' --cfg 'feature="termcolor"' --cfg 'feature="terminal_size"' --cfg 'feature="wrap_help"' -C metadata=4ceed62849ae43cd -C extra-filename=-4ceed62849ae43cd --out-dir /home/runner/work/conmon-rs/conmon-rs/target/x86_64-unknown-linux-gnu/release/deps --target x86_64-unknown-linux-gnu -L dependency=/home/runner/work/conmon-rs/conmon-rs/target/x86_64-unknown-linux-gnu/release/deps -L dependency=/home/runner/work/conmon-rs/conmon-rs/target/release/deps --extern atty=/home/runner/work/conmon-rs/conmon-rs/target/x86_64-unknown-linux-gnu/release/deps/libatty-22b7da72fe42b183.rmeta --extern bitflags=/home/runner/work/conmon-rs/conmon-rs/target/x86_64-unknown-linux-gnu/release/deps/libbitflags-6cb1025d00e25f61.rmeta --extern clap_derive=/home/runner/work/conmon-rs/conmon-rs/target/release/deps/libclap_derive-00e157025f887d45.so --extern clap_lex=/home/runner/work/conmon-rs/conmon-rs/target/x86_64-unknown-linux-gnu/release/deps/libclap_lex-2b215555cb1ffb97.rmeta --extern indexmap=/home/runner/work/conmon-rs/conmon-rs/target/x86_64-unknown-linux-gnu/release/deps/libindexmap-7a358f6b01a7a487.rmeta --extern once_cell=/home/runner/work/conmon-rs/conmon-rs/target/x86_64-unknown-linux-gnu/release/deps/libonce_cell-66a71340f1f3f5d8.rmeta --extern strsim=/home/runner/work/conmon-rs/conmon-rs/target/x86_64-unknown-linux-gnu/release/deps/libstrsim-dbf9aece6da0347b.rmeta --extern termcolor=/home/runner/work/conmon-rs/conmon-rs/target/x86_64-unknown-linux-gnu/release/deps/libtermcolor-6e0510c9f30bb93d.rmeta --extern terminal_size=/home/runner/work/conmon-rs/conmon-rs/target/x86_64-unknown-linux-gnu/release/deps/libterminal_size-21e8b1454d21cbd2.rmeta --extern textwrap=/home/runner/work/conmon-rs/conmon-rs/target/x86_64-unknown-linux-gnu/release/deps/libtextwrap-3512bba442108cbc.rmeta --cap-lints allow -C target-feature=+crt-static -L /usr/lib/x86_64-linux-gnu -L src/backend/linux_raw/arch/outline/release`

https://github.com/containers/conmon-rs/actions/runs/3573239142/jobs/6007068777

We build the static binary by cross compiling and pre-setting RUSTFLAGS="-C target-feature=+crt-static -L /usr/lib/x86_64-linux-gnu" cargo build -v --release --target x86_64-unknown-linux-gnu --features static

All dependencies are in place in our CI, but it still cannot pickup the static libraries from /usr/lib/x86_64-linux-gnu because the RUSTFLAGS are unset. Do you have any idea what we can do about this?

Enable Static aarch64 compilation in the CI

CI exists for aarch64, however the author of the recent static changes (aka me) did not update the CI to run a build aarch64 with static.

This led to a required hotfix (c043865)

I will start work on this tomorrow evening.