Remlab

• Home
• Articles & publications
• C.V. (PDF) / LinkedIn
• Contact

---

Projects

• ndisc6
• All Git repositories
• Web6 (in French)
• TI-89 & TI-92 programs

---

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.)

Cross-compilation

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

Contribs

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.

• First, the is the Rust toolchain (which we did not install with Debian). Rustc uses a more precise and systematic syntax to designate our platform: riscv64gc-unknown-linux-gnu instead of riscv64-linux-gnu.
• Then FFmpeg and its little sibling libpostproc fail because they insist on using a custom parameter and syntax to pass the ISA, even though they provide no optimisations for that ISA whatsoever yet.
• Worst of all is the gpg-error support library for GNU Crypto. This insists on knowing the size and alignment of the POSIX Threads mutual exclusion lock type (pthread_mutex_t) without using the dedicated <pthread.h> header. Thus it needs an ad-hoc version update for every new architecture or any new binary interface of the C run-time. It should be common sense not to do this, but go figure.

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.

VLC

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
make

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:

• Just like with contribs, platform-specific logic is necessary to detect support for the FPU at compilation time. Otherwise VLC will try to play it safe and use signed 16-bit PCM for all audio, and will not be able to apply audio filters.
• There is a bug, or at the very least, a very poor design decision in the RV64G Application Binary Interface (ABI) implemented by GCC versions 9 through 12. Namely 8- and 16-bit atomic variables use a locks with functions provided by the run-time library libatomic. RISC-V only provides register width and 32-bit atomic operations (in other words, 64-bit and 32-bit in our case), so 8- and 16-bit operations really should use 32-bit memory storage.

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.