> 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


Reply via email to