Re: [PATCH] Update config.guess and config.sub

[Liviu Ionescu <ilg at livius dot net>]

> On 5 Jul 2018, at 19:51, Palmer Dabbelt <palmer@sifive.com> wrote:
> 
> ... When I try to build it I see "Unsupported RISC-V target riscv-unknown-elf",

I guess configure is fine, you need to allow for the `riscv-` prefix in gcc/config.gcc, around line 3982

> so there's at least some extra autoconf wizadry that needs to happen in here.  I'm actually not sure what the "riscv-*" tuples are supposed to do so I've added Liviu as I don't want to misrepresent his desires and get into trouble again :).
> ...  My only constraint is that it doesn't break anything that currently builds, as I don't want to force a flag day on everyone because of this.

that's a reasonable desire.

however I guess that automatically transforming riscv- into riscv32- will break my builds.

if you take a look at the changes in my gcc fork, you'll see that later, in `config.gcc` I identify the `riscv-none-embed` tuple and provide a separate `elf-embed.h` instead of your `elf.h` which automatically links with libgloss. 

https://github.com/riscv/riscv-gcc/commit/5a282a3bc4e0f8700733dbf2c4d41aa528537e61

maybe this is not the best solution, but so far it worked.

if you have a better proposal, I am ready to consider it.

---

the requirements are simple:

- the resulting names of the binaries should not include any {32|64}; the idea to rename the binaries after the build is not acceptable
- the header file (elf.h) should be the edited one, which does not automatically link libgloss, since this is harmful for bare metal toolchains.

---

if for now the `-embed` suffix is not yet part of the script, I think I can continue to define it locally in my fork, until we have a RISC-V EABI and I can use `riscv-none-eabi-`.

however I think that adding it to the script is reasonable and might be also useful for other cross embedded toolchains that do not have an EABI.

---

generally speaking, I think that John proposal to clearly differentiate between Linux native compilers and cross embedded toolchains should be considered, it seems that he has a deep understanding of the problem and can provide a good solution.


regards,

Liviu