-
Notifications
You must be signed in to change notification settings - Fork 34
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
bpftool: Pass additional compile flags as EXTRA_CFLAGS, not CFLAGS #52
Conversation
Bpftool expects users to pass additional compilation flags via EXTRA_CFLAGS, not via CFLAGS. This is because when compiled from the kernel repo, CFLAGS are usually overwritten by the build system. When we build retsnoop with CFLAGS=--static, the static flag is passed down to bpftool's Makefile. Then we hit an issue: --static is ignored for feature probing at build time, but taken into account for the build itself. Under certain conditions this results in a discrepency and bpftool's Makefile believes LLVM support is available (given it tested without the --static flag) whereas it is not set up for static builds. Let's address this by passing retsnoop's CFLAGS via bpftool's EXTRA_CFLAGS, and resetting its CFLAGS. We must pass the CFLAGS to the "make" invocation through the environment, and not as a command line argument, to avoid overriding the CFLAGS values that we set inside of bpftool's Makefile. Reported-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Test dynamic and static builds for retsnoop on PRs. Test on amd64 only for now - but this should be easily extensible with the arm64 steps from the release workflow if necessary in the future. Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Bonus: I added a CI workflow to build retsnoop on pull requests, let me know if you prefer to discard it. |
Awesome, thanks a lot for CI build tests. Adding arm64 would definitely be great. I also wonder if static vs dynamic build would be better to split, so they can go in parallel? But yeah, this is awesome, thanks! |
I wondered too, but thought this would need to install the deps on a second runner and was not sure it was worth it. But yes, it would certainly go faster to run them in parallel. |
btw, I just created a draft release using CI action (https://github.com/anakryiko/retsnoop/actions/runs/6385199025), it all worked well this time. I'll be using this for the next release, thanks for your help! |
Great to hear! Did the |
Yep, I had to add I actually couldn't figure out how to do release without |
Before commit ad63eba, the workflow should have triggered every time someone pushes a tag matching the pattern It should have created a draft release automatically for the tag associated with the |
Bpftool expects users to pass additional compilation flags via
EXTRA_CFLAGS
, not viaCFLAGS
. This is because when compiled from the kernel repo,CFLAGS
are usually overwritten by the build system.When we build retsnoop with
CFLAGS=--static
, the static flag is passed down to bpftool'sMakefile
. Then we hit an issue:--static
is ignored for feature probing at build time, but taken into account for the build itself. Under certain conditions this results in a discrepency and bpftool'sMakefile
believes LLVM support is available (given it tested without the--static
flag) whereas it is not set up for static builds.Let's address this by passing retsnoop's
CFLAGS
via bpftool'sEXTRA_CFLAGS
, and resetting itsCFLAGS
. We must pass theCFLAGS
to the "make" invocation through the environment, and not as a command line argument, to avoid overriding theCFLAGS
values that we set inside of bpftool'sMakefile
.Related: #51 (comment)