Introduce Alternate Toolchain gcc and binutils#4063
Conversation
| BR2_OPENPOWER_PLATFORM=y | ||
| BR2_OPENPOWER_POWER9=y | ||
| # BR2_PACKAGE_PPE42_TOOLCHAIN is not set | ||
| BR2_PACKAGE_ALTERNATE_GCC=y |
There was a problem hiding this comment.
Are we going to set this variable for P10 configs too?
There was a problem hiding this comment.
we could if necessary... I believe we should strive to use buildroot's gcc + binutils the best we can, but if for some reason we need to update buildroot (say to fix security holes or bugs that are only fixed in more modern versions), we could set this setting, as well as the ALTERNATE_*_VERSION to keep hostboot and occ behind if necessary
| @@ -0,0 +1,56 @@ | |||
| ################################################################################ | |||
| # | |||
| # alternate-binutils | |||
There was a problem hiding this comment.
assuming all of this is identical to the current "primary" toolchain
| HOST_ALTERNATE_GCC_CONF_OPTS += \ | ||
| $(call qstrip,$(BR2_ALTERNATE_GCC_EXTRA_CONFIG_OPTIONS)) | ||
|
|
||
| define HOST_ALTERNATE_GCC_CONFIGURE_CMDS |
There was a problem hiding this comment.
I tried to make it as close to buildroot's as "necessary" - problem is that they are pretty spread out, and of course, possibly changing with each buildroot release.. see references at https://github.com/open-power/buildroot/blob/a84aaaeacbd1a69053cde2e50f26250e9328de1e/package/gcc/gcc.mk#L73 and https://github.com/open-power/buildroot/blob/a84aaaeacbd1a69053cde2e50f26250e9328de1e/package/gcc/gcc-final/gcc-final.mk#L62
We can probably make the conf command completely static and mimic the buildroot's command verbatin.. if we think this is necessary
There was a problem hiding this comment.
there's also the possibility of adjusting per-config options using BR2_ALTERNATE_GCC_EXTRA_CONFIG_OPTIONS
Hostboot, OCC and potentially other packages are *VERY* sensitive to GCC+binutils combinations (specially due to the use of libbfd to feed the custom linker/loader script). That means that the default buildroot toolchain can't be easily upgraded without risking hard-to-debug build and runtime issues that might be caused by the change of the compiler + binutils combination. Address this by creating (yet another) GCC + Binutils host packages pair that can be used, as an alternative to the one provided by buildroot. Doing so would allow such packages to stay (indefinitely) using their choice of gcc+binutils, while still allowing buildroot (and the Skiroot environment) to evolve and use newer versions / releases. Signed-off-by: Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com>
|
@dcrowell77 @zane131 should we merge this and monitor CI for the next few weeks? I guess we could revert it if anything... |
|
Sounds okay to me |
3 participants
Hostboot, OCC and potentially other packages are VERY sensitive to
GCC+binutils combinations (specially due to the use of libbfd to feed
the custom linker/loader script). That means that the default buildroot
toolchain can't be easily upgraded without risking hard-to-debug build
and runtime issues that might be caused by the change of the compiler +
binutils combination.
Address this by creating (yet another) GCC + Binutils host packages pair
that can be used, as an alternative to the one provided by buildroot.
Doing so would allow such packages to stay (indefinitely) using their
choice of gcc+binutils, while still allowing buildroot (and the Skiroot
environment) to evolve and use newer versions / releases.
Signed-off-by: Klaus Heinrich Kiwi klaus@linux.vnet.ibm.com