-
Notifications
You must be signed in to change notification settings - Fork 174
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
chore(cmake/modules) Bump bundled GRPC version to 1.44.0 #222
Conversation
Welcome @Molter73! It looks like this is your first PR to falcosecurity/libs 🎉 |
Hi @Molter73. Thanks for your PR. I'm waiting for a falcosecurity member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Hi @Molter73 ! Thanks for opening this PR! |
Mmmh CI fails with:
Can you try to build sinsp-example target in your container? |
Looks like they replaced Let me try recompiling, I may have some residual binaries in my env or something. I'm pretty sure changing the dependency here will get rid of the error though. |
Makes lot of sense! |
While you are at it, can you also double check all other "enforced" deps running, as advised, |
I've managed to get the same error locally and after fixing that dependency a bunch more unresolved dependencies showed up (because why wouldn't they?). I'm trying to fix compilation and will upload the change ASAP |
Ok, I'm in a bit of a pickle and could use a hand. I've run
Removing duplicates and comparing the libraries to the ones listed in "${GRPC_SRC}/third_party/abseil-cpp/absl/base/libabsl_core_headers.a"
"${GRPC_SRC}/third_party/abseil-cpp/absl/memory/libabsl_memory.a"
"${GRPC_SRC}/third_party/abseil-cpp/absl/types/libabsl_optional.a"
"${GRPC_SRC}/third_party/abseil-cpp/absl/random/libabsl_random_random.a"
"${GRPC_SRC}/third_party/abseil-cpp/absl/strings/libabsl_str_format.a"
"${GRPC_SRC}/third_party/abseil-cpp/absl/functional/libabsl_bind_front.a"
"${GRPC_SRC}/third_party/abseil-cpp/absl/container/libabsl_flat_hash_map.a"
"${GRPC_SRC}/third_party/abseil-cpp/absl/container/libabsl_inlined_vector.a"
"${GRPC_SRC}/third_party/abseil-cpp/absl/utility/libabsl_utility.a"
"${GRPC_SRC}/third_party/abseil-cpp/absl/types/libabsl_variant.a" Problem is that none of those libraries are being built, even though they are listed as dependencies and are defined in the abseil cmakelists, am I missing something here? I've also tried adding all |
Hi @Molter73 ! That is interesting; well bumping gRPC is always a somewhat interesting experience :) |
PS:
You ran it using grpc.pc script from your build folder, right? Not the system one. |
I ended up looking into the As for the
|
Top you are doing a superb job man! I am currently trying to build gRPC too on a fedora:35 container myself, trying to be more helpful! |
It built with no problems by just bumping grpc version to 1.44.0 on fedora:35 container O.O
That's weird; i just updated the grpc cmake submodule and run EDIT:
|
I had the same thing happen to me yesterday, it is possible that some of the libraries from the previous version are still lingering and it gets compiled against those instead of the new ones, try removing the whole grpc directory. I just managed to compile locally and trimmed back some libraries that ended up not being needed, I'm gonna try a full compilation from scratch to double check and I'll push the change if it succeeds. |
This is already using a clean build/ folder; i will retry. |
aaaand it worked again:
|
Oh wait! |
Uh that makes sense, thanks! Can reproduce it now. |
I'm guessing poiana is broken, I see the same failure in a separate unrelated PR. |
Yep, i am currently trying to fix it! |
Btw from your PR i was able to build |
Cool, thanks for letting me know it has worked for you too! |
/test build-libs |
The build will be fixed once #226 is merged in master (and you rebase). |
@Molter73 Can you rebase on master? Thanks! |
Signed-off-by: Mauro Ezequiel Moltrasio <[email protected]>
Signed-off-by: Mauro Ezequiel Moltrasio <[email protected]>
f161938
to
06633f3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/approve
LGTM label has been added. Git tree hash: 592f1ef39bd12286eea4e91d5affd4e943e1d3a8
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: FedeDP, Molter73 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/approve
…security#222) An unusual syntax of the declaration of a constructor (`libsinps::events::set<T>()`) raises a warning when the compiler is gcc-11 (of the Agentino’s builder) and the build is done with C++20. The warning is a blocker as we treat warnings as errors.
What type of PR is this?
/kind cleanup
Any specific area of the project related to this PR?
/area build
What this PR does / why we need it:
While running
make sinsp
using the bundled dependencies in a Fedora 35 container with GCC 11.2.1, compilation of the GRPC dependency was failing with the following message:error: no matching function for call to ‘max(long int, int)’
After doing some research, it looks like this has already been addressed by the abseil-cpp project and the change is present in GRPC's tag v1.44.0, in turn bumping to that version fixes the compilation error.
Dockerfile I'm using as a devcontainer just in case it is useful
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
/cc @leogr
/cc @FedeDP
Does this PR introduce a user-facing change?: