new(ci): use zig compiler instead of relying on centos7.

[FedeDP]

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:

• update(cmake): updated c-ares to latest 1.33.1 version. libs#2034 -> new c-ares builds with zig
• chore(userspace/libsinsp): only link libanl if present. libs#2036 -> libanl is not present under zig; fixes build
• cleanup(userspace/libscap): avoid the usage of non-portable (glibc specific) __gnu_cxx::stdio_filebuf libs#2037 -> title says it all
• chore(cmake): honor CMAKE_BUILD_TYPE while building bundled grpc and protobuf libs#2043 -> avoids Falco linking issue undefined symbol: google::protobuf::internal::InternalMetadata::~InternalMetadata()
• fix(userspace/libsinsp): fixed a couple of UBs libs#2045 -> fixes arm64 Trace/breakpoint trap issue for threadinfo and k8saudit plugin opening (source_plugin.c UB)
• fix(cmake): added zig workarounds for libelf and grpc cmake modules. libs#2049 -> cmake patches for libelf and grpc to support zig build
• fix(userspace/libsinsp): avoid possible UB when calling back or front without checking string emptiness libs#2088 -> more UBs fixes for libs

Linked upstream PR:

• lib: guard definition of strl{cat,cpy} against glibc version when _FORTIFY_SOURCE is enabled ziglang/zig#21253

TODO:

• sanitizer build fails at cmake configure step, because of: zig cc -fsanatize=address fails at link time on macOS ziglang/zig#11403. Workaround: disable zig for sanitizer builds, ie: only use it for to-be-shipped artifacts.
• arm64 build is failing while building abseil randen_hwaes.cc file, since their cmake tries to detect platform features and enforces -march=armv8-a+crypto, but armv8 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.
• fix test-dev-packages-arm64 -> it seems like a Trace/breakpoint trap is caught during sinsp::open... methods calls:

Tue Sep  3 10:46:35 2024: Loaded event sources: syscall
Tue Sep  3 10:46:35 2024: Enabled event sources: syscall
Tue Sep  3 10:46:35 2024: Opening 'syscall' source with Kernel module
Trace/breakpoint trap

• fix test-dev-packages-arm64 -> it seems like a Trace/breakpoint trap is caught related to stats_writer line: output_fields["falco.host_boot_ts"] = machine_info->boot_ts_epoch; -> bca6f31
• fix test-dev-packages-arm64 -> it seems like a Trace/breakpoint trap is caught related to k8saudit opening
• libelf is built bundled

Does this PR introduce a user-facing change?:

new(ci): use `zig` compiler instead of relying on centos7.

[poiana]

[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:

• OWNERS [FedeDP]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[FedeDP]

/milestone TBD

[FedeDP]

So, we need to disable the build with shared libelf, because zig statically links all specified libraries; see: ziglang/zig#7094
Indeed the CI complains it cannot find system libelf.
Since this was an 🌶️ topic for the CNCF, i am going to hold this PR; at the same time, i think we should actually find a way to drop centos:7 while maintaining same glibc requirements.

Anyway, even trying with BUNDLED_LIBELF, gives a build error...

/hold

[FedeDP]

Enabled bundled libelf to build with zig. Of course this is not desiderable.

[FedeDP]

Now failing the build on

ld.lld: error: undefined symbol: arc4random_buf

referenced by ares_rand.c:270

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 zig is not actually supporting it since we are targeting a build with glibc-2.17.

[FedeDP]

I tried to build c-ares from scratch (ie: without Falco involved at all) with zig and it worked fine with the same exports we are doing in the CI.

[FedeDP]

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. 🤞

[FedeDP]

So, i now bumped this branch to use libs chore/zig_build branch HEAD; that is a branch i pushed upstream with all zig related fixes on it:

• update(cmake): updated c-ares to latest 1.33.1 version. libs#2034
• chore(userspace/libsinsp): only link libanl if present. libs#2036
• cleanup(userspace/libscap): avoid the usage of non-portable (glibc specific) __gnu_cxx::stdio_filebuf libs#2037
• chore(cmake): honor CMAKE_BUILD_TYPE while building bundled grpc and protobuf libs#2043

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 CC and CXX strings at first whitespace, leading with cmake using zig as compiler for both, instead of zig cc and zig c++.
I created 2 small wrapper scripts in CI to workaround this issue:

cat > zig-linux-${{ inputs.arch }}-${ZIG_VERSION}/zig-cc << EOF
#!/bin/bash
zig cc -target ${{ inputs.arch }}-linux-gnu.2.17 "$@"
EOF
chmod +x zig-linux-${{ inputs.arch }}-${ZIG_VERSION}/zig-cc
echo "CC=zig-cc" >> $GITHUB_ENV

// same for zig-c++

[FedeDP]

To be able to build Falco, for now, i had to disable _FORTIFY_SOURCE, see my commit message: 0bb6f49

I opened an upstream issue to track the problem: ziglang/zig#21252 and a PR: ziglang/zig#21253

[FedeDP]

TODO:

• rebase on master and fix code fmt
• fix arm64 tests :/ -> this was caused by an UB In libs or Falco, will be fixed once we upgrade libs to the master with patch fix(userspace/libsinsp): avoid possible UB when calling back or front without checking string emptiness libs#2088

[github-actions]

This PR may bring feature or behavior changes in the Falco engine and may require the engine version to be bumped.

Please double check userspace/engine/falco_engine_version.h file. See versioning for FALCO_ENGINE_VERSION.

/hold

[leogr]

This PR may bring feature or behavior changes in the Falco engine and may require the engine version to be bumped.

Please double check userspace/engine/falco_engine_version.h file. See versioning for FALCO_ENGINE_VERSION.

/hold

False positive

[FedeDP]

Yep, tomorrow will rebase on latest libs master that fixes arm64 test-dev-packages and unhold this one :)

[FedeDP]

/unhold
Ready!

[FedeDP]

📢 it might happen that master build fails because the cached key (ie: zig version) is no more available and zig moved to a newer master version, thus we cannot find the correct zig version to be downloaded.
In that case, i'll update zig to latest in libs and restart the CI here.

[FedeDP]

/hold
until next week.

[FedeDP]

I'll keep this on hold until we release Falco 0.39.1 to avoid issues with the new CI.

[FedeDP]

/unhold
Let's see if master CI complains (i guess so :D )