Install GCC 10.4.0

[0intro]

This change installs GCC 10.4.0 on the following build images:

• deb-arm
• deb-x64
• rpm-arm64
• rpm-x64
• suse-x64

We chose to provide our own GCC version, because the GCC versions available as part of CentOS 6, openSUSE 42.1 and Ubuntu 14.04 weren't recent enough to build OpenSCAP and some of its dependencies.

We chose GCC 10.4.0, because it was the most recent version that could be built using the GCC versions available on our distributions. GCC 11 and upper include libcody, which is written in C++11 and requires a more recent GCC version to be built.

This change is the result of a collaborative work between Sylvain Baubeau, Pierre Guilleminot and David du Colombier.

[bkabrda]

👋 thanks for submitting the PR. Have you talked about this to other teams that maintain pieces of Agent code that get compiled by GCC? From top of my head, this would be agent-metrics-logs (rtloader) and agent-integrations (some Python integrations have C extensions that would get compiled by GCC). It would be good to try to standardize on one GCC version instead of adding more, if possible.

I'm also wondering whether it's practical to put the new GCC version under /opt/gcc-${GCC_VERSION}, because anything using this GCC will have to hardcode the specific GCC_VERSION and if we do even a minor version upgrade we'll have to fix all these places. Maybe it would be sufficient to have a path that would only contain GCC minor version, e.g. /opt/gcc-10?

[0intro]

Thanks for your review.

wave thanks for submitting the PR. Have you talked about this to other teams that maintain pieces of Agent code that get compiled by GCC? From top of my head, this would be agent-metrics-logs (rtloader) and agent-integrations (some Python integrations have C extensions that would get compiled by GCC). It would be good to try to standardize on one GCC version instead of adding more, if possible.

We have not talked to the other teams yet. Our goal was to introduce a recent GCC version in the build image, which is required to build some external dependencies (for example, libraries written in C++11). Then, the other teams will be able to use this recent GCC version.

Currently, the build of the Agent is relying on heterogeneous GCC toolchains provided as part of the various Linux distribution we support (RHEL, Ubuntu and SUSE). I think the ultimate goal is that everyone use a single, common, recent GCC toolchain we build ourself, instead of relying on the heterogeneity of the various Linux distribution.

I'm also wondering whether it's practical to put the new GCC version under /opt/gcc-${GCC_VERSION}, because anything using this GCC will have to hardcode the specific GCC_VERSION and if we do even a minor version upgrade we'll have to fix all these places. Maybe it would be sufficient to have a path that would only contain GCC minor version, e.g. /opt/gcc-10?

The GCC_VERSION variable is exported to the environment of the build image, so, when building the Agent, one could refer to the GCC_VERSION available.

It would be possible, for example, to export something like GCC_10_VERSION, or, as you suggested, use a fixed path /opt/gcc-10, but I think it would defeat the goal of having a single, common, modern, recent GCC version.
We defined a GCC_VERSION variable, like it was the case, for example, for CMAKE_VERSION already, but I think, similarly to what you suggested, that we could simply hardcode the path to something like /opt/gcc.

What do you think?

[bkabrda]

Hi 👋 the PR mostly LGTM, but I left couple notes and comments inline to get addressed.

[bkabrda]

The change LGTM, so I'm approving.

The two points that I'll leave up to you folks to address going forward are:

• The rpm-armhf addition of this gcc version when you figure out how to fix the compilation problem there.
• Talking to other Agent teams to consolidate on this new gcc version and stop using the old ones.

[jinroh]

rebased on 48c12a1

[0intro]

I split the addition of flex on the images where it was missing to a different commit.

[0intro]

Moved the addition of flex to a separate PR (#371).