Crates.io | libbpf-sys-cross |
lib.rs | libbpf-sys-cross |
version | 1.4.3+v1.4.5 |
source | src |
created_at | 2024-08-14 13:44:40.598512 |
updated_at | 2024-08-14 13:44:40.598512 |
description | Cross-compilation friendly fork of libbpf-sys |
homepage | https://github.com/kxxt/libbpf-sys-cross |
repository | https://github.com/kxxt/libbpf-sys-cross |
max_upload_size | |
id | 1337364 |
size | 16,624,809 |
This crate is probably temporary. In the end I want to upstream all changes back to libbpf-sys.
Rust bindings to libbpf from the Linux kernel
Maintainer: Alex Forster <alex@alexforster.com>
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...
The community is encouraged to build higher-level crates using libbpf-sys. Please let me know if you do!
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
LIBBPF_SYS_EXTRA_CFLAGS
can be used to pass extra cflags when vendoring libbpf, libz or libelf.LIBBPF_SYS_LIBRARY_PATH
: colon separated pathes for the linker to find native libs.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.
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
.
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 |