toolchain: Add support for Sourcery Codebench Standard
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 3 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 3 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [Buildroot] [PATCH 0/3] toolchain: Add support for Sourcery Codebench Standard
Dear Romain Naour,
Quoted 5 lines · Romain Naour
The purpose of this series is to provide support for Sourcery Codebench Standard (licenced) edition in Buildroot.
Since these toolchain can't be downloaded, we need to use the custom toolchain backend to import them into Buildroot.
Thanks for this patch series. As we discussed today during the meeting, the currently proposed implementation is a bit fragile because:
* SYSROOT_DIR is empty/invalid in your situation, while most of the code assumes SYSROOT_DIR exists. While your patches make sure every time SYSROOT_DIR is used, we fallback to ARCH_SYSROOT_DIR if SYSROOT_DIR doesn't exist, this may break in the future, especially as we don't have access to this proprietary Sourcery Codebench toolchain to test and check that future changes will keep this toolchain working.
* the dance with faking a SYSROOT_DIR being different from ARCH_SYSROOT_DIR by one path component is really highly specific to this toolchain, and will not work in other situations.
Consequently, the proposal is to:
* Change the SYSROOT_DIR/ARCH_SYSROOT_DIR detection logic so that if SYSROOT_DIR is empty/bogus, then the same value as ARCH_SYSROOT_DIR is used. This ensures that both SYSROOT_DIR and ARCH_SYSROOT_DIR point to valid directories (which would the same in the case of this toolchain, which brings us back to the non-multilib toolchain case).
* Adjust the symlink logic to handle a new case: when SYSROOT_DIR == ARCH_SYSROOT_DIR, look again at the real sysroot directory, and if it's bogus, then it means we in fact have a multilib toolchain that may need a symbolic link. If that's the case, then using -print-sysroot with no flags, -print-sysroot with flags, and computing the common part of both paths, we get the "base sysroot".
Thinking about it, we might also think of using the strategy described above to find the "base sysroot" and use this value in SYSROOT_DIR, no?
In the mean time, I'll mark the three patches as Changes Requested in patchwork.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com