Re: [meta-arm] [PATCH 0/4] external-arm-toolchain: Add support for SDK generation

["Denys Dmytriyenko" <denis@denix.org>]

On Mon, Jun 08, 2020 at 04:56:54PM +0530, Sumit Garg wrote:
> On Fri, 5 Jun 2020 at 04:30, Denys Dmytriyenko <denis@denix.org> wrote:
> >
> > On Tue, Jun 02, 2020 at 04:34:50PM +0530, Sumit Garg wrote:
> > > Patch #1 and #2 adds impprovements in external-arm-toolchain recipe in order to
> > > support SDK generation. SDK generation has been tested using:
> > >
> > > $ bitbake core-image-base -c populate_sdk
> >
> > This just ensures that external-arm-toolchain doesn't get in the way of SDK
> > generation by avoiding any conflicts. The only re-use here is glibc. The rest
> > of pre-built Arm toolchain gets thrown out and rebuilt from sources - gcc,
> > binutils, gdb/gdbserver are all built from sources as TCMODE was not set and
> > falls back to "default".
> 
> Yes I noticed this as well. I guess we can improve this situation to
> package tools from pre-built toolchain only rather than building from
> source. Will explore options.
> 
> > Sure, pre-built Arm toolchain doesn't provide all
> > possible SDKMACHINE binaries, but for 90% cases of x86_64, there's very little
> > re-use...
> 
> Yes, but don't you think that having a common build environment using
> SDKs is still useful from the end user's perspective irrespective of
> underlying toolchain (built from source or pre-built)?

Just wanted to get back to this point.

Yes, in general that would be preferred (and exactly why OE insists on 
building everything, starting with the toolchain, compared to competitors 
that use prebuilt toolchains by default, like buildroot, etc).

But as you have seen from the discussion in the other thread, there are 
some legitimate (hopefully) reasons to re-use prebuilt binaries even for 
SDK - licensing, distribution and such...

Back in the day it was simpler - 32-bit x86 was dominant and what prebuilt 
toolchain supported as a host and being the default/only SDKMACHINE.

For some time Linaro toolchain supported both 32-bit and 64-bit x86 as a
host, so it was possible to support both of those SDKMACHINEs. These days 
32-bit x86 faded into obscurity. But on the other hand, aarch64 hosts are 
gaining traction, so targeting aarch64 SDKMACHINE from x86 host will be a 
problem with external-arm-toolchain w/o full rebuild of SDK toolchain...

So, hopefully this can be done optionally/conditionally to either re-use 
prebuilt binaries from external toolchain or build them from sources.

-- 
Denys