-
Notifications
You must be signed in to change notification settings - Fork 895
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
wip: new(ci): use zig
compiler instead of relying on centos7.
#3307
base: master
Are you sure you want to change the base?
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: FedeDP 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 |
/milestone TBD |
So, we need to disable the build with shared libelf, because Anyway, even trying with BUNDLED_LIBELF, gives a build error... /hold |
cmake -B build -S . \ | ||
-DCMAKE_BUILD_TYPE=${{ inputs.build_type }} \ | ||
-DUSE_BUNDLED_DEPS=On \ | ||
-DUSE_BUNDLED_LIBELF=On \ |
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.
Enabled bundled libelf to build with zig. Of course this is not desiderable.
e6e593c
to
8925c1f
Compare
Now failing the build on
That's probably because c-ares does some magic to detect that symbol: https://github.com/c-ares/c-ares/blob/main/CMakeLists.txt#L456; that symbol was added in glibc2.36; most probably it is detecting the symbol even if |
I tried to build |
Update: i saw that updating c-ares to 1.33.1 (latest release) fixed the issue. I am going to bump it in libs (if possible, ie: if grpc does not complain :/ ) Bump PR in libs: falcosecurity/libs#2034 I now bumped this one to use head of the libs PR with the updated c-ares. 🤞 |
So, i now bumped this branch to use libs
On that branch, i was able to build a full BUNDLED_DEPS version of sinsp-example! Moreover, i found out that CMAKE_{C,CXX}_COMPILER truncates
|
70e175a
to
73b8ed5
Compare
To be able to build Falco, for now, i had to disable I opened an upstream issue to track the problem: ziglang/zig#21252 and a PR: ziglang/zig#21253 |
903ec35
to
1bf6742
Compare
file(GLOB patches "*.patch") | ||
file(MAKE_DIRECTORY ${PROJECT_BINARY_DIR}/libs-patches/) | ||
foreach(p ${patches}) | ||
configure_file("${p}" "${PROJECT_BINARY_DIR}/libs-patches/" @ONLY) |
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.
libelf patch uses @CMAKE_SYSTEM_PROCESSOR@
thus it needs to be configured.
@ONLY
to avoid touching also normal cmake variables like ${FOO}
.
The PR is ready; idea is to merge this right after the Falco release, after falcosecurity/libs#2034, falcosecurity/libs#2037 and falcosecurity/libs#2049 are merged in Falco libs (i'll then take care of update this PR to use libs master of course). Then, we will have 4 months to discover any new issue and fix it. Finally, leveraging the newly introduced composite action to install zig, i will also add a CI job on libs to test build against zig so that we make sure we will never break the zig build ;) |
20bef12
to
c500eac
Compare
fff3ebf
to
ec56c9c
Compare
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Improve CI workflow by adding wrapper scripts zig-cc and zig-c++ to be used as environment vars `CC` and `CXX`, since cmake var `CMAKE_{C,CXX}_COMPILER` does truncate those variables to their first part (ie: before the first whitespace), otherwise leading to issues, since only `zig` would be used as compiler by cmake. Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
…d bump actions checkout. Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
It causes weird issues with zig finding the prototypes for `strlcat` and `strlcpy` in `lib/libc/include/generic-glibc/bits/string_fortified.h`, but their implementation is not present, leading to link time build failure. This means: * check_symbol_exists(strlcpy "string.h" HAVE_STRLCPY) fails * `HAVE_STRLCPY` and `HAVE_STRLCAT` are not defined * `<libscap/strl.h>` defines both `strlcat` and `strlcpy` * but `string.h` included at the start of `strl.h` will find the prototypes, thus failing because of symbol redefinition Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
…on any system. Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
…g bug is now solved. Also, switch to a development version of zig with the patch merged. Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
… debug builds. Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
…ranch. Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
…en running against zig. Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
ec56c9c
to
0db5aa2
Compare
What type of PR is this?
/kind cleanup
Any specific area of the project related to this PR?
/area CI
What this PR does / why we need it:
This PR drops centos7 from our CI by instead relying on zig compiler to provide glibc 2.17 compatible builds for us.
Which issue(s) this PR fixes:
Fixes #3270
Special notes for your reviewer:
Linked libs PRs:
__gnu_cxx::stdio_filebuf
libs#2037 -> title says it allundefined symbol: google::protobuf::internal::InternalMetadata::~InternalMetadata()
Trace/breakpoint trap
issue for threadinfo and k8saudit plugin opening (source_plugin.c UB)TODO:
zig
for sanitizer builds, ie: only use it for to-be-shipped artifacts.-march=armv8-a+crypto
, butarmv8
is unsupported by zig. Workaround: patch https://github.com/abseil/abseil-cpp/blob/1031858eb2b87a5d47f236d8eac11d8b05c535d5/absl/copts/GENERATED_AbseilCopts.cmake#L225 to use a supported arch name.test-dev-packages-arm64
-> it seems like aTrace/breakpoint trap
is caught duringsinsp::open...
methods calls:test-dev-packages-arm64
-> it seems like aTrace/breakpoint trap
is caught related to stats_writer line:output_fields["falco.host_boot_ts"] = machine_info->boot_ts_epoch;
-> bca6f31test-dev-packages-arm64
-> it seems like aTrace/breakpoint trap
is caught related to k8saudit openingDoes this PR introduce a user-facing change?: