2018-06-22 3:17 GMT+02:00 DJ Delorie <d...@redhat.com>: > > If by this patch you mean that "riscv-unknown-linux-gnu" means EITHER > riscv32 (when on a 32-bit os) OR riscv64 (when on a 64-bit os), then I > would prefer *against* this, as it would mean that config.guess would > return an ambigious value - there is no version of GNU/Linux that > supports both riscv32 and riscv64 at the same time. > > Keeping the 32/64 suffix is consistent with the s390/s390x case right > below it, where s390 is 31-bit and s390x is 63-bit, rather than having > one name mean "either". > > We also don't combine x86_64 and i*86, and *one* chips supports both of > those. > > I have no problem with users selecting riscv-* explicitly, or toolchains > shortening prefixes. TPF does this (resulting programs are like > tpf-gcc, not tpf-something-else-gcc) for example. But that shouldn't be > config.guess's job. Config.guess is used for more than the toolchain's > default program name.
Thanks for articulating this so well. I have the same opinion, adding ambiguity will cause more problems than benefits. Besides, in Debian we even have a tendency to do the other way around and be more explicit, for example substituting calls from "gcc" to the explicit riscv64-linux-gnu-gcc or other targets, and it helps quite a lot in some cross-compilation situations. If I understand this correctly, this change would probably make things more difficult when compiting for riscv32 from a riscv64 system. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> _______________________________________________ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
