Add per-target LIBBPF_SYS_LIBRARY_PATH env var to help cross-compilation #139
Conversation
README.md
Outdated
|
|
||
| - `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. | ||
| - `LIBBPF_SYS_LIBRARY_PATH_<TARGET>`: similar to `LIBBPF_SYS_LIBRARY_PATH`, but used to set per-target library path, to help cross-compilation environments. If `LIBBPF_SYS_LIBRARY_PATH_<TARGET>` and `LIBBPF_SYS_LIBRARY_PATH` are defined, the paths from both will be used. |
There was a problem hiding this comment.
We should probably clarify that this is the target triple. "target" is pretty much as ambigious as it gets and at least that would be marginally better.
build.rs
Outdated
| env::var(global_lib_path), | ||
| env::var(target_lib_path), | ||
| env::var(target_lib_path_underscored), |
There was a problem hiding this comment.
Should these be ordered so that the "global" thing is last? My understanding is that ordering matters and if we don't try the more specialized one first, can't we run into cases where we still end up picking the wrong library? After all, the linker will likely pick the first present library it finds.
There was a problem hiding this comment.
I wouldn't expect anyone to actually specify both, but I do agree the "target" one should take precedence
|
Hey, let me know if the changes look good, and I'll squash them for the merge. As for testing, I have opened a repository to help test cross-compilation for Android - #amirbou/libbpf-cross-compile. It depends on a fork I made for It first prepares the library dependencies ( Let me know if you have any questions about it :) |
danielocfb
left a comment
danielocfb
left a comment
There was a problem hiding this comment.
Seems fine to me now. Please go ahead and squash and we can get this in. Thanks!
amirbou
force-pushed
the
per-target-sys-library-path
branch
2 times, most recently
from
7f45f02 to
a263929
Compare
…ross-compilation environments This solves an issue when cross-compiling an application that uses libbpf-sys in build.rs(Usually via libbpf-cargo). In that case, the libbpf-sys crate is built twice - once for the host triplet (let's say x86_64-unknown-linux-gnu, when compiling build.rs) and once for the target triplet (let's say aarch64-linux-android, when compiling the actual application). If we set `LIBBPF_SYS_LIBRARY_PATH` to a path that contains the libelf for the target triplet, then `build.rs` will link to the incorrect library, failing the build.
amirbou
force-pushed
the
per-target-sys-library-path
branch
from
a263929 to
237815d
Compare
3 participants
This solves issue #106
Add per-target LIBBPF_SYS_LIBRARY_PATH environment variable to help cross-compilation environments.
This solves an issue when cross-compiling an application that uses libbpf-sys in build.rs(Usually via libbpf-cargo).
In that case, the libbpf-sys crate is built twice - once for the host triplet (let's say x86_64-unknown-linux-gnu, when compiling build.rs) and once for the target triplet (let's say aarch64-linux-android, when compiling the actual application).
If we set
LIBBPF_SYS_LIBRARY_PATHto a path that contains the libelf for the target triplet, thenbuild.rswill link to the incorrect library, failing the build.I have taken a similar approach as the
BINDGEN_EXTRA_CLANG_ARGS_<TARGET>flag inrust-bindgenallowing for both underscores and hyphens for the target.