You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This change overhauls the vendoring & static linking features that the
library exposes. Please refer to the larger discussion [0] for
additional context, but in short: we introduce separate features for
vendoring/linking each of the three system library dependencies: libbpf,
libelf, zlib. "static" and "vendored" meta-features are still available,
which apply to all three libraries in unison. The remaining dependencies
are expressed declaratively via dependent features. E.g., because zlib
is only a dependency of libbpf (and not a direct one), linking it
statically implies linking libbpf statically. In the future, this design
would make it possible to enable additional configurations. For example,
currently vendoring any library implies linking it statically, because
we only build the static version. This is more of a simplification than
a strict requirement and if needed, we could support dynamic linking
when using a vendored copy.
We could alternatively move to a model where we err out on combinations
that make little sense/are risky/whatever. Doing so could be beneficial
if we ever were to loosen some of those dependencies down the line to
minimize chance of breakage. I am unsure how likely that really is or
whether it would be cause for concern, and I generally like the
declarative nature of "this feature depends on this other" in
Cargo.toml, but we could change that if we feel strongly.
The default features mirror the previous default and no behavior change
should occur. The existing novendor feature is kept but deprecated and
should be removed in the future (a warning will be printed as part of
the build). It was certainly one of the main causes of confusion where
novendor and vendored could co-exist and it was hard to understand what
would or wouldn't happen. In the new world, users are advised to simply
build with all features disabled.
I tested everything on a binary depending on libbpf-sys with various
features enabled and spot checked the expected dynamic library
dependencies. We could enshrine that as a CI step, but given that this
logic is expected to change infrequently I didn't go down that road.
[0] libbpf#64 (comment)Closes: libbpf#70
Signed-off-by: Daniel Müller <[email protected]>
0 commit comments