[PATCH] Update config.guess and config.sub
Liviu Ionescu
ilg@livius.net
Thu Jul 5 17:23:00 GMT 2018
> 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
More information about the Gcc-patches
mailing list