Package Details: riscv64-unknown-elf-binutils 2.34-1

Git Clone URL: (read-only, click to copy)
Package Base: riscv64-unknown-elf-binutils
Description: Assemble and manipulate binary and object files for 32bit and 64bit RISC-V
Upstream URL:
Keywords: risc-v
Licenses: GPL
Submitter: esmil
Maintainer: esmil
Last Packager: esmil
Votes: 4
Popularity: 0.000003
First Submitted: 2017-09-10 11:57
Last Updated: 2020-03-23 19:18

Latest Comments

esmil commented on 2020-09-08 07:45

Hi maribu,

Yes, I guess that's one valid reading of that document, but I don't think it's something Archlinux should maverick. Debian, Ubuntu and even the toolchains built by SiFive are all called riscv64-unknown-elf-, and I really don't want to be in a situation where some poor soul downloads eg. zephyr, but now because they're on Archlinux they need to learn CMake and the whole zephyr build system to figure out how to change riscv64-unknown-elf- to riscv64-elf-, riscv64-none-elf or whatever Archlinux choose to call it.

maribu commented on 2020-09-08 07:18

Shouldn't the triple be riscv64-none-elf? According to, unknown means "I don't care, go with the defaults". But shouldn't we expect the defaults to possibly change?

xiretza commented on 2020-03-24 10:56

It builds in a clean chroot - you're right though, if built on a dirty system with a libc installed, it assumes libstdc++ is installed as well and fails. Since a failed test wouldn't be noticed anyway, maybe comment out the make check though? Anyone who wants to properly run the tests has to change the PKGBUILD either way, and if they're completely disabled by default, everyone else doesn't have to wait for the tests to complete (and won't be unsettled by failing tests).

esmil commented on 2020-03-24 07:50

Thanks, but it still fails. It seems to want a stdc++ library for the target for most of the tests that fail. I'm not going to add a dependency on that or we'd have a cyclic dependency and this package would have to be built more than once.

If you have a problem with this, please file a bug against ..on which this was modelled.

xiretza commented on 2020-03-24 01:40

Did you really just turn the entire testsuite into an expensive no-op by always making it pass? Just commenting out the make check would be a lot more efficient at that point. Anyway, here's a patch that fixes the testsuite instead of ignoring it:

AndrevS commented on 2018-04-30 20:08

The package seems to build fine, but the check() fails.