> On 5 Jul 2018, at 19:51, Palmer Dabbelt <pal...@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