Building upstream RISC-V GCC+binutils+newlib: the quick and dirty way

gistfile1.txt

Building upstream RISC-V GCC+binutils+newlib: the quick and dirty way
September 5, 2017

There are a number of available options for building a RISC-V GCC toolchain. You might use the build system from the riscv/riscv-tools repository, or investigate toolchain generators such as crosstool-ng. However in the case of riscv-tools, it’s not always clear how this corresponds to the code in the relevant upstream projects. When investigating a potential bug, you often just want to build the latest upstream code with as little fuss as possible. For distribution purposes you’d probably want to perform a proper multi-stage build, but for a quick test you might find the following recipe useful:

git clone --depth=1 git://gcc.gnu.org/git/gcc.git gcc
git clone --depth=1 git://sourceware.org/git/binutils-gdb.git
git clone --depth=1 git://sourceware.org/git/newlib-cygwin.git
mkdir combined
cd combined
ln -s ../newlib-cygwin/* .
ln --force -s ../binutils-gdb/* .
ln --force -s ../gcc/* .
mkdir build
cd build
../configure --target=riscv32-unknown-elf --enable-languages=c \
--disable-shared --disable-threads --disable-multilib --disable-gdb \
--disable-libssp --with-newlib \
--with-arch=rv32ima --with-abi=ilp32 --prefix=$(pwd)/built
make -j$(nproc)
make install

This will produce a newlib toolchain targeting RV32IMA in the built/ subdirectory. When files are duplicated in the newlib, binutils and gcc repositories, the gcc version takes precedence.

Major credit to everyone who worked on getting these toolchain ports upstream (Kito Cheng, Palmer Dabbelt, and others).

If you want a stable tree that's known to work well with RISC-V, the RISC-V organization maintains a tree that's awesome. It doesn't chase the build-of-the-day, but it has tags of everything (assembler, linker, compiler, simulator, openocd, etc.) you need to succeed. I really appreciate that team for doing the integration work because it's hard to figure out if a compiler is emitting a bad opcode or the assembler just isn't new enough to accept a new opcode and so on. Debuggers are even worse.

This is what's used in the MacOS Homebrew RISC-V tools. You can squint through the Ruby and find inspiration in their patches, tags, and build recipies. Homebrew syncs to the riscv-collab tree and sprinkles a tad of magic Mac dust and usability to serve a wide audience of chips and needs.

Risc64-blah is the default; 32-bits are available by twiddling -march and -mabi in your Makefile. As a result of all the languages and multilibs built, the tree will be heavier than yours, but you can use your configure syntax and their git tree and sweeten to taste.

Thanx for helping advance RISC-V.

Thanks for sharing.