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

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]

As weird as it seems, this stupid cast fixed a SIGTRAP generated on debug builds by zig.
If i removed the pragma pack from the scap_machine_info struct, the issue went away. Most probably this is just a bug somewhere in how zig/clang compile the sources.

[FedeDP]

libelf patch uses @CMAKE_SYSTEM_PROCESSOR@ thus it needs to be configured.
@ONLY to avoid touching also normal cmake variables like ${FOO}.

[FedeDP]

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.
Also, as soon as i'll have some spare time, i'd like to benchmark the new binary (eg: by locally building sinsp with zig and running make bench on it, since we now have a bunch of google benchmarks in libs, and doing the same from Falco master).

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 ;)