Compile as statically linked binary

[myhro]

Hi. Continuing the issue #390 investigation (which started on #600), I've confirmed that Beyla fails to start on Debian 11 (Bullseye) when using a binary compiled on Debian 12 (Bookworm) due to GLIBC version incompatibilities:

$ sudo ./bin/beyla
./bin/beyla: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./bin/beyla)
./bin/beyla: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./bin/beyla)
$ ldd --version | head -2
ldd (Debian GLIBC 2.31-13+deb11u7) 2.31
Copyright (C) 2020 Free Software Foundation, Inc.

Following the suggestion of producing statically linked binaries, it appears that simply disabling CGO was enough to make it work:

$ sudo ./bin/beyla
time=2024-02-02T14:29:16.109Z level=INFO msg="Grafana Beyla" Version=v1.1.0-81-g74a333c5 "OpenTelemetry SDK Version"=1.18.0
time=2024-02-02T14:29:16.112Z level=ERROR msg="Beyla couldn't start read and forwarding" error="can't instantiate instrumentation pipeline: validating configuration: missing BEYLA_EXECUTABLE_NAME or BEYLA_OPEN_PORT property, or a 'discovery' section in the configuration file. Please check the documentation for more information"

Do you think this is a reasonable solution to the problem of running Beyla on systems with older versions of GLIBC?

Closes #390.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (74a333c) 69.49% compared to head (9a1d8b4) 79.87%.

Additional details and impacted files

@@             Coverage Diff             @@
##             main     #601       +/-   ##
===========================================
+ Coverage   69.49%   79.87%   +10.37%     
===========================================
  Files          67       70        +3     
  Lines        5826     5942      +116     
===========================================
+ Hits         4049     4746      +697     
+ Misses       1498      974      -524     
+ Partials      279      222       -57     

Flag	Coverage Δ
integration-test	69.51% <ø> (+0.01%)	⬆️
unittests	44.61% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[grcevski]

LGTM! Thanks again Tiago!

I checked all the vendor code which uses import "C" and I can't see anything that's relevant for Beyla. I think this will work.

@mariomac what do you think? If this resolves our Debian buster libc compatibility issues it's a great win.

[grcevski]

Sorry it took a while to review, we were at FOSDEM talking about distributed tracing with eBPF :).

[myhro]

I checked all the vendor code which uses import "C" and I can't see anything that's relevant for Beyla. I think this will work.

I was expecting a compilation error in cases like that, but looks like this isn't how it works. Like this Go SQLite example:

$ CGO_ENABLED=0 go build -o sqlite-example
$ ./sqlite-example
2024/02/05 11:06:21 "Binary was compiled with 'CGO_ENABLED=0', go-sqlite3 requires cgo to work. This is a stub":
        create table foo (id integer not null primary key, name text);
        delete from foo;

All we get is a runtime error.

Maybe also running go test with CGO_ENABLED=0 might help us to be sure?

If this resolves our Debian buster libc compatibility issues it's a great win.

Debian 10 (Buster) probably won't work with the default 4.19 kernel, but the 5.10 kernel is available in the backports.

What's the actual target? Debian 10 (Buster) or Debian 11 (Bullseye)?

Sorry it took a while to review, we were at FOSDEM talking about distributed tracing with eBPF :).

No problem at all. I'll be in the lookout for the recording. :-)

[mariomac]

Interesting! I'd expect that "CGO_ENABLED=0" was the default value.

[grcevski]

Debian 10 (Buster) probably won't work with the default 4.19 kernel, but the 5.10 kernel is available in the backports.

Thanks @myhro, sorry I got the names confused, I meant bullseye really :).