-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmake: always link to packaged libbpf if CMAKE_USE_LIBBPF_PACKAGE is set #3210
Conversation
[buildbot, test this please] |
CMake's NAME_WLE was introduced in v3.14, changed to NAME_WE which is available in older releases. Let's see if this works or it needs permissions: |
[buildbot, test this please] |
1 similar comment
[buildbot, test this please] |
[buildbot, ok to test] |
Some of the executables still link to the local static versions even if the user requested CMAKE_USE_LIBBPF_PACKAGE. Fix this by using bcc-shared-no-libbpf more widely if the variable is set.
…PF_PACKAGE is set Skip the git submodule and the extraction commands if the user set CMAKE_USE_LIBBPF_PACKAGE
The build failure on the Ubuntu CIs was due to the order of linker flags being changed - on some compilers it matters. I've fix it and restored the original order - bpf-static first, then its dependencies (elf/zlib). |
@yonghong-song gentle ping for review. We will be using these patches in the upcoming Debian 11 release (and as a consequence in the next Ubuntu release and other derivatives). TIA! |
The change looks good to me. Thanks! |
…set (iovisor#3210) Some of the executables still link to the local static versions even if the user requested CMAKE_USE_LIBBPF_PACKAGE. Fix this by using bcc-shared-no-libbpf more widely if the variable is set. Skip the git submodule and the extraction commands if the user set CMAKE_USE_LIBBPF_PACKAGE
For some binaries, even if CMAKE_USE_LIBBPF_PACKAGE is set static linking is still used, breaking expectations. If the option to use the packaged version is set, it should be respected.