Search Criteria
Package Details: riscv64-unknown-elf-binutils 2.43.1-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/riscv64-unknown-elf-binutils.git (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: | http://www.gnu.org/software/binutils/ |
Keywords: | risc-v |
Licenses: | GPL |
Submitter: | esmil |
Maintainer: | Maxr1998 |
Last Packager: | Maxr1998 |
Votes: | 9 |
Popularity: | 0.017948 |
First Submitted: | 2017-09-10 11:57 (UTC) |
Last Updated: | 2024-09-07 15:02 (UTC) |
Dependencies (2)
- binutils
- zlib (zlib-ng-compat-gitAUR, zlib-gitAUR, zlib-ng-compat)
Latest Comments
1 2 Next › Last »
leuko commented on 2023-04-03 14:51 (UTC) (edited on 2023-04-03 15:00 (UTC) by leuko)
What is the difference of this package to the riscv64-elf-binutils in the official repo? In short, is there a difference between the targets
riscv64-unknown-elf
andriscv64-elf
?robng15 commented on 2022-08-14 06:54 (UTC)
I would not have renamed the package, except for:
https://archlinux.org/packages/community/x86_64/riscv64-elf-gcc/
from the main repository requiring it to be named
riscv64-elf-binutils
as a dependency. I only posted what I'd done for reference, I'd rather not have had to make the above change. Relatively new to Arch, but needed an updated binutils for my FPGA project.
Sorry for any offence.
esmil commented on 2022-08-11 10:14 (UTC)
Please don't rename the tools. The bare-metal toolchains distributed by SiFive and all other big distributions are called riscv64-unknown-elf- which means a lot of projects and tools like fx. Zephyr expects the bare-metal toolchain for RISC-V to be called that.
robng15 commented on 2022-08-11 09:20 (UTC)
Thanks for this. I'd done
https://github.com/rob-ng15/PAWSv2/tree/main/SOFTWARE/resources/ARCHLINUX-AUR/riscv64-unknown-elf-binutils
As needed it to be called riscv-elf-binutils for compatability with gcc.
Does allow use of various extra extensions.
Maxr1998 commented on 2022-07-01 17:12 (UTC) (edited on 2022-07-01 17:38 (UTC) by Maxr1998)
Adopted package & updated to 2.38.
esmil commented on 2020-09-08 07:45 (UTC)
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 (UTC)
Shouldn't the triple be
riscv64-none-elf
? According to https://clang.llvm.org/docs/CrossCompilation.html#target-triple, 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 (UTC)
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 (UTC)
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 https://www.archlinux.org/packages/community/x86_64/arm-none-eabi-binutils/ ..on which this was modelled.
xiretza commented on 2020-03-24 01:40 (UTC)
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: https://gitlab.com/snippets/19561781 2 Next › Last »