So far, we didn't have the stack variable initialized, so we probably
can keep it like that for a little while longer. The stack variable
initialization gets enabled by default with gcc 12, because gcc 12
supports the -ftrivial-auto-var-init flag. Such configuration is
saved, and is reused for building the external modules.
It's something that we normally would want to have enabled, but this
breaks building falco-module, because despite falco Docker images
having multiple versions of gcc, the versions go from 5 to 8, and
neither support the -ftrivial-auto-var-init flag. The error is as follows:
* Running dkms build failed, dumping /var/lib/dkms/falco/e1d0fd9b043f1c7dfd91c9d030c11cfe2c062931/build/make.log (with GCC /usr/bin/gcc-8)
DKMS make.log for falco-e1d0fd9b043f1c7dfd91c9d030c11cfe2c062931 for kernel 5.15.96-flatcar (x86_64)
Fri Mar 3 16:17:58 UTC 2023
'/tmp/falco-dkms-make' -C /lib/modules/5.15.96-flatcar/build M=/var/lib/dkms/falco/e1d0fd9b043f1c7dfd91c9d030c11cfe2c062931/build modules
make[1]: Entering directory '/host/lib/modules/5.15.96-flatcar/build'
warning: the compiler differs from the one used to build the kernel
The kernel was built by: x86_64-cros-linux-gnu-gcc (Gentoo Hardened 12.2.1_p20230121-r1 p10) 12.2.1 20230121
You are using: gcc-8 (Debian 8.3.0-6) 8.3.0
CC [M] /var/lib/dkms/falco/e1d0fd9b043f1c7dfd91c9d030c11cfe2c062931/build/main.o
gcc-8: error: unrecognized command line option '-ftrivial-auto-var-init=zero'
make[2]: *** [/host/lib/modules/5.15.96-flatcar/source/scripts/Makefile.build:289: /var/lib/dkms/falco/e1d0fd9b043f1c7dfd91c9d030c11cfe2c062931/build/main.o] Error 1
make[1]: *** [../source/Makefile:1905: /var/lib/dkms/falco/e1d0fd9b043f1c7dfd91c9d030c11cfe2c062931/build] Error 2
make[1]: Leaving directory '/host/lib/modules/5.15.96-flatcar/build'
make: *** [Makefile:16: all] Error 2
Using one compiler for the kernel and then a different compiler to
build the module certainly made me to raise my eyebrows. Maybe we
should rather try building a module using the developer container, and
if this succeeds - document it.
ROOTPATH is not a thing any more. And with recent portage update, it
stopped being handled in some special way. Just use PATH. This should
unbreak stage2 of our SDK build, where the failure was:
/usr/bin/env: ‘bash’: No such file or directory
I changed the way we modify the ebuild by keeping the modifications as
minimal as possible, leaving disabling whatever that can be disabled
to the USE flags.
Instead of accepting everything blindly with exception of licenses
from CHROMEOS and EULA group (which are dropped from overlay anyway,
as we were not shipping anything with those licenses), accept the
Gentoo default licenses (basically licenses from the FREE group) and
some extra licenses on top.
This also uncovered some more places that will require some cleanups
(mostly firmware packages that need syncing).
This is to make sure that the directory layout wrt. lib directories in
stage1 is correctly set up from the beginning, because it gets
propagated all the way to the final SDK image. It's easier to do it
that way, rather than following the steps described in the deprecation
notice of the 17.0 profile.
Pull in a new version of baselayout to have a proper setup of lib
directories in stage1. The proper setup means that the `lib` entry is
now a directory instead of a symlink to `lib64`.
Honestly, when rewording this commit, I realized that this hook is not
really needed, as the updated baselayout ebuild just drops code that
became dead after the profile update that the other hook does. But I
decided to keep it as is, because the CI build with this hook has
passed, and this hook will be needed anyway by the weekly updates.
We have moved away from it already in production images already. With
the change of profile from 17.0 to 17.1, SYMLINK_LIB is always "no",
so some code will never be executed. Drop it.
