We’re working to complete our SDK integration for MultiZone Security - the first Trusted Execution environment for RISC-V - and have run into some issues with the precompiled toolchain on Ubuntu 18.04.
Following the install guide:
clone the git repository
download the risc-v tools and openocd
update the variables for RISCV_PATH and RISCV_OPENOCD_PATH
make clean (which works)
make software (which works)
make upload which produces two errors
/home/dbarnets/riscv-openocd-20180928-x86_64-linux-ubuntu14/bin/openocd -f bsp/env/freedom-e300-hifive1/openocd.cfg &
/home/dbarnets/riscv64-unknown-elf-gcc-20180928-x86_64-linux-ubuntu14/bin/riscv64-unknown-elf-gdb software/demo_gpio/demo_gpio --batch -ex “set remotetimeout 240” -ex “target extended-remote localhost:3333” -ex “monitor reset halt” -ex “monitor flash protect 0 64 last off” -ex “load” -ex “monitor resume” -ex “monitor shutdown” -ex “quit” &&
echo “Successfully uploaded ‘demo_gpio’ to freedom-e300-hifive1.”
/home/dbarnets/riscv-openocd-20180928-x86_64-linux-ubuntu14/bin/openocd: error while loading shared libraries: libftdi1.so.2: cannot open shared object file: No such file or directory
/home/dbarnets/riscv64-unknown-elf-gcc-20180928-x86_64-linux-ubuntu14/bin/riscv64-unknown-elf-gdb: error while loading shared libraries: libmpfr.so.4: cannot open shared object file: No such file or directory
The libftdi1.so.2 error is a library that does not appear to be bundled with the precompiled GNU toolchain - it is in Freedom Studio however. I’m not srue if this issue is unique to 18.04 or a broader dependency issue.
The libmpfr.so.4 error is more problematic - Ubuntu stopped bundling this package with 18.04, thus it seems the only fixes are to do a symbolic link (which is a bit of a hack) or to recompile the toolchain in Ubuntu (which I did and works fine but takes a long time).
Any solutions to make the precompiled toolchain work with Ubuntu 18.04?
Building portable binaries is a hard thing to do, and the SiFive build procedures (both openocd and gcc) do not produce portable binaries.
The build scripts used by GNU MCU Eclipse are far more elaborated, and the generated binaries are checked during the build to avoid still refering to shared libraries, so the resulting static binaries should run on most distributions.
“sudo apt install libftdi1-dev” should fix the first problem. The second problem is a bigger one. The fact that the libmpfr library name changed suggests ABI incompatible changes. You would need a copy of the library from Ubuntu 16.04 to make this work. I don’t know if there is an easy way to do that offhand. And using an older version of the library might require older versions of other libraries too.
As Liviu mentioned, building portable binaries is hard, and clearly we have some work to do here. I can pass this info along to the other software team members and discuss solutions. Maybe we should be building fully static binaries for instance. Or maybe it is good enough to force static versions of the gmp/mpfr/mpc libraries that gcc/gdb use as those are the most problematic ones. Meanwhile building your own toolchains should work and does appear to be working for you.
My concern is the user experience - if you purchase a dev board and follow the instructions you arrive at a dead end; the only resolution is to spend 20-60 minutes rebuilding the toolchain locally (more if your network is slow).
If the precompiled binaries do not work consistently, it may be better to remove them and force users into a local toolchain build than to have a dead end.
What surprises me is that the pre-build Freedom Studio works flawlessly on Ubuntu 18.04 - is it just getting more usage and therefore more frequent updates than the GNU toolchain?
It usually works… until you do an update/upgrade that changes some library and then it no longer works, and you have to build it again and hope for the best.
Given that after many thousand downloads (9k+ for the GCC RISC-V toolchain, many more for OpenOCD, for example) I did not get any complains, I would say that my portable binaries work nicely on Windows 32/64, Linux 32/64 (from CentOS 6 up) and macOS (from 10.10.5 up).
I’ve never looked at Freedom Studio, always using the raw GNU toolchain. On Ubuntu 18.04 for the last six months, incidentally.
I don’t find building it onerous. It’s about 20 minutes on my pocket-sized NUC, or as low as 5 minutes on a server/i9/ThreadRipper, depending on whether you do newlib or glibc and whether you do a single library version or multilib.
I do agree that if you supply precompiled binaries then they should be a bit more robust than something you build just for yourself.
This means that the build procedures were not consistent, so, even if based on the same source base, the toolchains were probably built in different environments, with different build scripts.
For consistent result, the build environment should be tightly controlled, and guaranteed to not change inadvertently over time (I use Docker images, which are read-only by definition).