[Buildroot] [arc-buildroot] [PATCH 1/6] package/gcc: remove special arc version

[Alexey Brodkin]

Dear Waldemar, Yann, all,

Sorry for a bit late reply.

> On 2023-12-31 18:25 +0100, Waldemar Brodkorb spake thusly:
> > Signed-off-by: Waldemar Brodkorb <wbx at openadk.org>
>
> Thanks for working on this; we discussed that with Thomas the other day,
> and we concluded that indeed that would be a good idea to get rid of
> that special version now.
>
> However, your commit log is empty. It should instead explain the reasons
> why dropping that special version is now a good thing.
>
> It is very importaant that this information be recorded in the commit
> log, because we may (will!) need to refer to it in the future, when we
> then wonder why that was good idea.

Thanks for that clean-up series and indeed it makes a lot of sense for
ARCompact (AKA ARCv2) & ARCv2 processors - which are perfectly supported in
all the upstream projects.

Especially it's nice that you went that far and added confing and instuctions
on how to run the Linux kernel for ARC on QEMU - that's much appeciated.

But as we discussed some time age there's ARCv3 ISA which support is being
added in upsream components still and as of now not all the bits and pieces
got merged upstream, thus we and our user have to rely [sadly again] on our
GitHub forks, see [1], [2] and [3]

Funny enough uClibc as you know already has full support of ARCv3 starting from 
v1.0.43, see [4].

What's also nice, both 32-bit and 64-bit versions of ARCv3 are well supported in our QEMU
fork [5], so relevant configutations will be included as well.

So given that's a short new year break between work fires I may quickly send-out
patches which will either:
1. Bump ARC tools to the latest version 2023.09 (see [6]) which will also
   add support for ARCv3 (in fact we already have it in our fork, see [7])
2. Update ARC tools (GCC, Binutils/GDB & glibc) for ARCv3 only, while switching
   ARCompact & ARCv2 to upstream components.
3. Given ARC seems to be the only use of non-upstream components, remove
   ARC-specific tools/forks from buildroot and  only enable ARCv3 use via
   external toolchains.

And while (3) is the slimmest option (no need to add or rather maintain ARC-specific)
code in package/xxx Config.in.host, xxx.mk especially with uClibc it's a bit too
restrictive as users may want more flexibility of configuring uClibc to their needs.

-Alexey

[1] https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/tree/arc-2023.09
[2] https://github.com/foss-for-synopsys-dwc-arc-processors/binutils-gdb/tree/arc-2023.09
[3] https://github.com/foss-for-synopsys-dwc-arc-processors/glibc/tree/arc-2023.09
[4] https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=de6be7bc60f190a0d746945a3a5a143bc93a1a65
[5] https://github.com/foss-for-synopsys-dwc-arc-processors/qemu
[6] https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/tag/arc-2023.09-release
[7] https://github.com/foss-for-synopsys-dwc-arc-processors/buildroot/tree/arc-2023.09