[RFC] add script to generate and package a binary toolchain #5162
Conversation
|
Does this / Can this address the #4719 rust glibc mismatch? |
No that's completely unrelated. |
was <naïvely> hoping ... Guess I could always build x86 from Arch64 - lol... I'll work on getting myself a HH 2.33 glibc docker buildhost - that works. |
|
Before packages go to mirrors, --march=native should be removed from host cflags. config/optimize line 12.
This means building everything other than the kernel with a premade toolchain too? |
|
Shouldn't this be device specific in some way? |
No, the idea is to create a device agnostic toolchain |
This is a great point. I'll have to think about the best solution for that. In the mean time this still is considered WIP.
Possibly. We have talked about splitting the toolchain from the build completely but I'm not really sure if that is a good idea. The solution provided here should just be considered as an alternative to the external toolchains that we already have to provide. |
|
I've updated the PR to allow disabling host optimizations I've uploaded a test tarball here: it would be good if someone can verify it would on their system: |
|
Two issues: First is the gcc wrapper is hardcoding your $TOOLCHAIN path resulting in:
Good news, I edited the wrapper to remove ccache (I don't use it), and pointing to where i extracted the tarball and 10.2.0 popped out in response. Second issue is many symoblic links are being made with the same underlying issue with $TOOLCHAIN, resulting in broken links: https://pastebin.com/raw/WJmW5cYh |
|
Does |
|
Some more thoughts from working with this a little: For consideration: antonlacon@6b86f63 The symbolic link issue can be solved at time of the tarball creation by dereferencing the links (tar -h) to duplicate the files. I believe that building Size in comparison to the arm-provided toolchain is bigger than what is built here (+40MB compressed, +150(?)MB uncompressed). I believe this is because build dependencies are being packaged in, when it should just need runtime dependencies. Packaging python3 is a significant chunk of the size difference. |
This is something I've been looking at for a while. I don't like having to use external toolchains to build our images and would like to be able to at least use our own generated toolchain if we can.
This initial step allows generating an aarch64 toolchain to be used in the arm 64/32 split builds. This will replace the arm toolchain package
gcc-arm-aarch64-none-linux-gnu.I've thought about going further to generate a toolchain that would actually replace building the toolchain when generating an image, but I'm not sure I want to go down that road yet.
Ideally this could be expanded to cover all of the external toolchains that we need but I'm not sure the extent of that yet.
This should be tested on all platforms (that use 64/32 split) before continuing (I've only build tested for now). I've also not pushed any packages to the mirrors.
If you want to test you will need to generate your own package for now:
Usage:
Output:
A Toolchain version file is generated and inserted into the packaged toolchain. This file is printed after the archive is generated