On Wed, 21 Nov 2018 at 01:32, Trevor Woerner <tre...@toganlabs.com> wrote:
>
> The hexagon toolchain (4.6.1) from kernel.org, for example, was packaged in
> a way that is different from most toolchains. The first entry when unpacking
> most toolchain tarballs is:
>
>         gcc-<version>-nolib/<targetarch>-<system>
>
> e.g.:
>
>         gcc-8.1.0-nolibc/aarch64-linux/
>
> The first entry of the hexagon toolchain, however, is:
>
>         gcc-4.6.1-nolibc/
>
> This causes the buildman logic in toolchain.py::ScanPath() to not be able to
> find the "*gcc" executable since it looks in gcc-4.6.1-nolib/{.|bin|usr/bin}
> instead of gcc-4.6.1/hexagon-linux/{.|bin|usr/bin}. Therefore when buildman
> tries to download a set of toolchains that includes hexagon, the script fails.
>
> This update takes the second line of the tarball unpacking (which works for
> all the toolchains I've tested from kernel.org) and parses it to take the
> first two elements, separated by '/'. It makes this logic a bit more robust.
>
> Signed-off-by: Trevor Woerner <tre...@toganlabs.com>
> ---
>  tools/buildman/toolchain.py | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Reviewed-by: Simon Glass <s...@chromium.org>

BTW I really appreciate your great commit msg.

- Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Reply via email to