Added a cross-compilation subpackage for aarch64 into gcc.

[PawelWMS]

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

• The toolchain has been rebuilt successfully (or no changes were made to it)
• The toolchain/worker package manifests are up-to-date
• Any updated packages successfully build (or no packages were changed)
• Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
• Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
• All package sources are available
• cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
• LICENSE-MAP files are up-to-date (./SPECS/LICENSES-AND-NOTICES/data/licenses.json, ./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md, ./SPECS/LICENSES-AND-NOTICES/LICENSE-EXCEPTIONS.PHOTON)
• All source files have up-to-date hashes in the *.signatures.json files
• sudo make go-tidy-all and sudo make go-test-coverage pass
• Documentation has been updated to match any changes to the build system
• Ready to merge

---

Summary

WARNING: requires #6945 for full build or the fast-track PR check run.

Continuation of #6945 and the remainder of the changes from #5569. This change adds a cross-compilation version of gcc.

Change Log

• Added cross-compilation build bits into gcc.spec.
• Small spec clean-up.

Does this affect the toolchain?

Yes.

Associated issues

• Add cross-compiler packages #5569
• Added cross-compilation binutils and kernel-headers. #6945

Test Methodology

• Local package build and test.

• Full build after merging Added cross-compilation binutils and kernel-headers. #6945 inside the pawelwi/dadelan/cross_full_test branch.

• Fast-track style PR check from the same pawelwi/dadelan/cross_full_test branch.

• Verified I was able to build ARM64 glibc binaries by following an online article starting from the "Install glibc headers and bootstrap libraries" step (earlier steps are handled by installing the new cross-compilation packages) all the way to the "Build and install glibc for the target system". I skipped the "Build and install libgcc" step as libgcc is already provided inside the new gcc subpackage.

  Notes for the "Install glibc headers and bootstrap libraries" instructions:

  • Set PREFIX=/usr and TARGET=aarch64-linux-gnu.
  • Used --with-headers=$PREFIX/arm64-linux-gnu/include instead of the path from the article, since our path is a bit different.

[dmcilvaney]

Haven't had a chance to look at the binutils pr, is there a set of pro/cons around for having a single .spec versus a dedicated cross version of the spec?

[PawelWMS]

Haven't had a chance to look at the binutils pr, is there a set of pro/cons around for having a single .spec versus a dedicated cross version of the spec?

Having it all in one file makes it definitely more robust, but splitting into separate spec files make it harder to track version upgrades and CVE fixes, as they will have to be duplicated among these separate specs.

My main worry with a single spec is that we're adding the package to the toolchain without a good reason, but I decided to postpone the solution until we enable custom per-spec macros - the idea you mentioned to me in December, which would allow us to build the same spec but with a slightly different configuration.

[PawelWMS]

No changes to the default configuration - just putting the arguments in alphabetical order whenever possible.:)