Re: [meta-arm] External toolchain support

["Sumit Garg" <sumit.garg@linaro.org>]

Hi Paul,

I think first we need to understand the implementation of this recipe.
The recipe itself does *not* fetch the pre-built toolchain by itself
but it is rather dependent on the user to download and install
toolchain on the host machine and thereby provide toolchain install
path via variable "EXTERNAL_TOOLCHAIN".

In order to use any of pre-built Arm toolchain versions (8.2, 8.3 and
9.2), a user just needs to specify following in conf/local.conf:

TCMODE = "external-arm"
EXTERNAL_TOOLCHAIN = "<path-to-the-toolchain>"

- Eg. for AArch64 (eg. qemuarm64 machine in poky distro)
EXTERNAL_TOOLCHAIN =
"<installation-path>/gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu"

- Eg. for AArch32 (eg. qemuarm machine in poky distro)
EXTERNAL_TOOLCHAIN =
"<installation-path>/gcc-arm-9.2-2019.12-x86_64-arm-none-linux-gnueabihf"

So with the above framework, the toolchain recipe isn't tied to a
single version of pre-built toolchain (or single source for which
toolchain is built) but rather is flexible to support various
pre-built toolchains which can differ in following aspects:
- Host machine.
- Arm 32bit or 64bit toolchain.
- Multiple toolchain versions.

On Wed, 20 May 2020 at 01:34, Paul Barker <pbarker@konsulko.com> wrote:
>
> Hi all,
>
> As discussed on the Yocto Project call today it's great to see the ARM
> toolchain recipes moving forward under the new meta-arm layers. I've
> had some issues in the past with the external pre-built toolchain
> which really need fixing to properly integrate this toolchain into
> projects. I'm raising them here in the hopes that these can now be
> fixed.
>
> 1) Maintaining GPL compliance while using an external toolchain
>
> The Yocto Project has an archiver class which can be used to collect
> the source code of all packages built by bitbake which is a
> requirement for meeting the terms of the GPL. However for the external
> toolchain recipes the "source" is the pre-built toolchain archive
> downloaded from the ARM website. As the pre-built toolchain includes
> glibc (which is then distributed as part of the images we build) what
> we need is the actual source code used to build the various toolchain
> components.
>
> The toolchain recipe needs to include some link to the actual upstream
> sources and the archiver class in oe-core probably needs extending to
> support this.

As I mentioned above, it's not the recipe which fetches the pre-built
toolchain but the user provides a path to the pre-installed toolchain.
And the user can easily navigate through the sources from where the
toolchain is built on the download page (see section "Sources" here
[1]) itself.

[1] https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-a/downloads

>
> 2) Building an SDK/ESDK
>
> If an SDK is generated for an image built with the pre-built toolchain
> then there can be some confusion about what exactly should provide the
> gcc binary and various headers. In the past I've had to hack
> components out of the SDK after it is built and then tell customers to
> install the pre-built toolchain alongside the SDK in order to get a
> working cross-compiler. Ideally everything should actually get
> packaged into the SDK so that only one download is needed and no
> hard-coded paths are used.

As I mentioned above a hardcoded path is needed to provide flexibility
and to avoid having duplicate recipes for every pre-built toolchain
variant.

AFAIK, with SDK all the headers and libraries should be pre-installed.
It's only the cross-compiler path which is derived from
EXTERNAL_TOOLCHAIN that needs to be specified in conf/local.conf.

>
> Additionally, running the populate_sdk task often fails due to missing
> packages (libatomic-dev right now) and it looks like the recipe
> bitrots fairly quickly after each fix. SDK generation needs to be
> regularly tested and it needs to be confirmed that these SDKs can
> actually cross-compile working binaries.

Did you give external-arm-toolchain a try? Simply do "bitbake
external-arm-toolchain" and you could see libatomic-dev package:

tmp/work/aarch64-poky-linux/external-arm-toolchain/2019.12-r0/pkgdata/runtime/libatomic-dev

>
> 3) Toolchain recipe is effectively split between meta-arm & meta-arago layers
>
> The bbappends carried in meta-arago fix items which are missing from
> the external-arm-toolcahin recipe in meta-arg (e.g. the installation
> of the ldconfig binary). That effectively splits the recipe over
> multiple layers as these things are pretty fundamental parts of the
> external-arm-toolchain recipe. An effort needs to be made to merge alls
> this together and have the base recipe well tested.
>

I am not sure from where you got the reference that meta-arago is
needed to build external-arm-toolchain. external-arm-toolchain is an
independent recipe and any fixes should be pushed to meta-arm only.

Regarding ldconfig, did you give external-arm-toolchain a try? I could
see it being packaged here:

tmp/work/aarch64-poky-linux/external-arm-toolchain/2019.12-r0/pkgdata/runtime/ldconfig

> 4) No example configurations or visible test matrix
>
> The meta-arm-toolchain layer lacks a README or other file providing
> some examples of working build configurations which use the pre-built
> toolchain. It's unclear which MACHINEs and DISTROs are regularly
> tested and are well supported. The best way to solve this would be to
> actually store the test scripts and configurations in this layer and
> use a publicly visible CI system like Travis, GitLab CI, etc to run
> the tests. That would increase confidence in the pre-built toolchain
> and make it clear what is supported and how frequently it's tested.

I agree with you here that we atleast need a CI system to test every
fix that goes in external-arm-toolchain in order to maintain quality.

It's only two variables "TCMODE" and "EXTERNAL_TOOLCHAIN" for a
particular build to use a pre-built toolchain. We can have a README to
describe their purpose as well.

Regarding MACHINEs and DISTROs testing, I would like to point to ARM
GCC 9.2 integration release announcement [1] where you could find the
test status just prior to when we made this recipe import from
meta-linaro to meta-arm.

[1] https://lists.yoctoproject.org/g/yocto/message/48094

>
> 5) LICENSE is incorrectly stated in the external-arm-toolchain recipe
>
> The full license of the toolchain package needs to be specified. Right
> now all packages are marked as having the MIT license which is
> obviously not correct for most of them.

I guess you missed below comment:

# License applies to this recipe code, not the toolchain itself.

How do you envision to have a separate license file for every package
provided by a single recipe "external-arm-toolchain.bb"? Also, given
there is single "EULA" file available from the downloads page [1].

[1] https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-a/downloads

-Sumit

>
> Apologies for the long rant but I hope this is useful to highlight
> some of the issues seen when trying to practically use the pre-built
> ARM toolchain.
>
> Thanks,
>
> --
> Paul Barker
> Konsulko Group
>