Building VLC for RISC-V

Support for a whole new instruction set architecture (ISA) is a somewhat rare occurence in VLC development. In recent times, a partial port to the sui generis WebAssembly instruction set, was completed, though that is not a traditional machine ISA. Before that, the last added ISA was 64-bit ARMv8-A, or rather AArch64, as it is officially designated. That goes back to 2013 on Apple devices.

The last ISA to be (barely) added first on Linux-based systems was MIPS a year earlier. On GNU/Linux, it was 32-bit ARM: version 7 was added in 2009 though there were already embryonic ARMv6 ports in the earlier years. At the time, the current build system for underlying libraries did not even exist yet.

Development boards with general-purpose/application RISC-V processors have now appeared, so it is about time to do this again. RISC-V is particularly interesting for open-source in that it is the first truly open (license-free) general-purpose ISA with some real momentum. (Note: yes, I know that some other ISAs have become open, but they are all obsolscent and more or less dead by now.)


I do not yet personally have a RISC-V device, but that does not mean that porting cannot start yet.

Nowadays Debian-based Linux distributions provide complete toolchains for many architectures, including 64-bit RISC-V. Cross-compilation for Linux across different architectures has become a lot easier than in the past, whence you had to hunt for a working toolchain, or even assemble your own.

On Debian Sid, this works out-of-the-box:

apt-get install g++-riscv64-linux-gnu


The VLC build system is divided in distinct two parts. (Well actually, it is divided in three parts, but the third one is not useful on Linux and I will not use or cover it here.) Before building the proper LibVLC library and the VLC application, we need a build dozens of underlying open-source libraries and tools which may or may not be provided by the target system.

This is the job of the contribs build system. As of today, it contains well over a hundred different libraries. Normally they come with the Linux distribution, so contribs is not used, even though its current version was specifically meant to handle Linux systems better. Instead, it is mostly used for proprietary (Apple, Microsoft) and partially proprietary (Google) platforms.

The unfortunate consequence is that it is poorly tested on Linux. With the Debian cross-compilation toolchain, the only libraries that really comes with the system are the C run-time library, that is to say glibc. As such, if we cross-compile contribs, we end up building a lot more packages that we typically would in a native Linux build... and we hit a number of latent bugs that are not necessarily caused by the new ISA.

But regardless if introducing a whole new ISA, problems are to be expected for various reasons. After addressing a few preexisting issues, we are left with a few failing packages that really want ISA-specific build rules.

Additionally, we need to make one change to the build system itself to detect if (single precision) floating point is supported in hardware. By default, it would otherwise favour integer implementations of audio codecs.

On RISC-V, there is a standardised C preprocessor variable for that exact purpose: __riscv_flen. It is undefined if the FPU is not available, 32 if single precision is supported, and 64 if both single and double precisions are supported.


Once contribs are built, we can proceed with the VLC build system. Though there are plans to switch over to Meson eventually, it is still based on GNU autotools at the time of writing. Either way it works as any well-behaved C/C++ open-source program:

mkdir build
cd build
../configure -C --host=riscv64-linux-gnu \
        --disable-qt --disable-vdpau --enable-debug

And with that, we can build most of VLC and find further problems, though we will be missing the GUI, Wayland, PulseAudio support as well as both OpenGL and Vulkan for the time being due to the crude cross-compilation environment. Also we can only get the embedded SALSA subset of ALSA.

In practice, the source code handles 64-bit platforms properly, as VLC has been running on x86_64 (then ARMv8) for many years. This left two problems with RISC-V proper:

So then...

With all that, we are able to sort out quite a few (build) problems without even accessing actual hardware or even using an emulator. But at this point, we cannot do much more without one of those. Hopefully, there will be some continuation to this first part, but I cannot promise anything, so we will see.