The project I am working with requires a GCC version 7.5.0 or older in order to compile. I had originally tried to cross compile the project using Crosstool-NG and setting the compiler version to 7.5.0 but got stuck when the project required numpy libraries to be installed for my RISC-V compiled python. Basically I can not use pip to install numpy for this RISC-V python version because I am running an x86 CPU and python is cross compiled for RISC-V.
So this issue led me to try native compilation on a Hifive Unleashed U540 using the RISC-V Fedora Linux. I have the package manager and everything works great on the board, but the on board GCC is version 10.
Does anyone know if it is possible to downgrade this to version 7.5.0 or earlier? I know it exists but I cannot seem to get it working on the system.
I found a gcc-7.3.1-5.0.riscv64.fc28.riscv64.rpm online and tried to install it but could not get it working.
I also tried a native install of Crosstool-NG but it ran for hours and crashed. Same story for the risv-gnu-toolchain
riscv-gnu-toolchain is not designed to support native builds. Don’t try to use it. But you don’t need it. if you have a system running riscv64-linux you can build a toolchain directly the usual way, e.g. configure build install binutils, then configure build install gcc using the same prefix for both binutils and gcc. The only tricky part is you need --disable-multilib for the gcc configure.
Don’t try to modify the system compiler. That will break stuff. You need to install your 7.x compiler in one of your own directories, or maybe in /opt.
gcc-7.3.1 is the very first stable FSF GCC release for RISC-V. You can’t use anything older than that. I do know that gcc-7.3.1 works. I’ve bootstrapped it natively.
An rpm for fc28 is not going to work on fc33 which I think is the current one. You can either try to find an old fc28 system, or simpler is probably to build just gcc from sources on the system you have.
crosstool-NG is for building cross compilers. You don’t need that either. Since crosstool-NG will build a complete toolchain including glibc, this will be harder to get working than just doing a simple binutils/gcc build directly.
In general, binutils/gcc work best when using versions released around the same time.
So my recommendation is download binutils-2.30 and gcc-7.3.1. Create a binutils build dir, and do
…/binutils-2.30/configure --prefix=
make -j4 all
make install
then create a gcc build dir and do
…/gcc-7.3.1/configure --prefix= --disable-multilib
make -j4 all
make install
then put /bin on your path and /lib on LD_LIBRARY_PATH and you should have a working gcc-7.3.1 based toolchain. It should take about 12 hours for the gcc build and a few more hours for the binutils build.
The system will be a little faster if you use NFS mounted disk for the binutils and gcc builds.
I just did a riscv-gnu-toolchain --enable-multilib build on a Pi4 running 64 bit Ubuntu. It took 102.5 minutes, which I thought was pretty slow compared to 15m13s in an Ubuntu VM (4 GB RAM, 4 cores) on an M1 Mac Mini. The Pi4 was just running on the SD card which didn’t seem to be a limiting factor, but they’ve improved the SD a lot in the 4 (and the SD on the Unleashed is particularly slow just because SiFive wanted to get it out the door three years ago).
On an unleashed with NBD root, a gcc bootstrap is 9 hours, and it was about 8.5 hours using nvme/sata when my expansion board was working. Yes, the SDcard is slow. I avoid it as much as possible. But also, the chip isn’t very fast. It isn’t in the same class as a pi4. It is probably a little slower than a pi3.
Another issue with gcc bootstrap speed is the agressive linker relaxation. The current implementation is order n-squared in the number of relocations. So it takes a long time to link big binaries like cc1 and cc1plus. That really slows down the gcc bootstrap time. I haven’t timed it for cc1 recently but I know that some of the large generated testcases in the glibc library take about an hour to link. We really need a volunteer to rewrite the RISC-V linker relaxation support to make it linear, or at least n-log-n, to reduce link times. That is likely to significantly speed up gcc bootstrap times. Meanwhile, any benchmark that includes compile+link time is going to make RISC-V look worse than ARM. If you are using the GNU toolchain that is. You might get different results with LLVM.
My experience generally shows the Unleashed at 1.4 GHz as a bit faster than the original 1.2 GHz Pi 3, slower than the 1.4 GHz Pi 3+. The 8 GB of DDR4 2400 helps a lot. And the gigabit ethernet. The A53 is dual-issue, but not actually all that much of the time.
Improving the Big O of relaxation sounds like something I could do, if there’s some money around to do it.
I have not touched the clock speed yet so it should be running default 1.5 GHz.
And I have just been building everything in their own folders in my Home directory.
Thank you so much for the detailed reply!
The board is in a remote location so I will have to stick with fc33 and build binutils/gcc from source.
I will try this out ASAP.