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

["Yann E. MORIN" <yann.morin.1998@free.fr>]

Alexey, All,

Thank you for quickly jumping ship in the discussion, Alexey!

On 2024-01-01 14:43 +0000, Alexey Brodkin via buildroot spake thusly:
> > On 2023-12-31 18:25 +0100, Waldemar Brodkorb spake thusly:
> > > Signed-off-by: Waldemar Brodkorb <wbx@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.
[--SNIP--]
> 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.

As you said, the ARCv2 is perfectly supported in the upstream
components. Then it makes sense to no longer have the ARC specific
versions for the ARCv2 CPUs, especially since that version (10.x) is
older than the oldest generic version we have (11.x).

Furthermore, we currently have no ARCv3 CPU support in Buildroot.

So, I think that, looking at the situation *as it is today*, Waldemar's
series (improved with the various comments I made earlier) is the best
course of action for Buildroot.

Then, when we get support for ARCv3 CPUs, we can either:

  - use your option 2 above if that comes before we remove the current
    ARC-specific version, or

  - reintroduce an ARC-specific version otherwise.

> 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.

I agree that option 3 is not very interesting.

Regards,
Yann E. MORIN.

> -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
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot