Over the past couple of days I have ported the NymphCast network streaming project [1] to Haiku, which was fairly straightforward due to its POSIX-compatibility. In this article I’ll describe my experiences with porting to what is effectively BeOS’ spiritual successor.

Haiku as a porting target is attractive for a number of reasons. The first is as mentioned that it is POSIX-compatible, meaning that any software written for Linux, BSD, etc. can be ported with zero to minimal changes. Another property that makes Haiku attractive is due to how light-weight it is, with a very rapid installation, and boot-up taking mere seconds, something which makes it appealing for low-end and embedded systems.

Although Haiku is still under development, with the porting taking place on the Beta 4 release as well as a nightly build of Beta 5 (to be released in 2024, possibly?), the only issues that I encountered during development in VirtualBox VM instances was an odd, occasional soft-lock during periods of high I/O activity that required resetting the virtual system, and some package versioning oddities [2] that got fixed by running pkgman update in a terminal to update the system.

As the first step towards porting NymphCast, I had to ensure that I could compile the NymphRPC [3] dependency first. This one was easy, as all it took was installing the Poco dependency with: pkgman install poco poco_devel and running Make. In Haiku’s pkgman system, the runtime package is always just the name of the project (like poco), and if there are development files such as libraries and header files, these are in a package with _devel as postfix.

Figuring out where the header files and freshly compiled static and shared libraries of NymphRPC had to go after this was the next challenge. The documentation for this is admittedly rather poor, but I got help from one of the Haiku developers – Mr. Waddlesplash – on Mastodon [4]. When running make install on NymphRPC now, it copies the aforementioned files to /boot/system/non-packaged/develop/{headers/lib}, which makes them available to the GCC and other compiler toolchains.

Of note here is that the Haiku filesystem is somewhat curious, with a number of overlays, symlinks and the like which make it seem more complicated than it is. Essentially, the entire boot drive containing Haiku and everything else is mounted on /boot, with the system folder containing (shockingly) system files, including files installed from packages (under packages) and those which were installed from elsewhere (non-packaged). This latter folder is thus similar to the /usr/local folder on Linux.

With NymphRPC now compiled and installed into its develop folders, I was able to compile libnymphcast [5], which encapsulates a lot of basic NymphCast functionality useful for primarily clients, but also the server component. After installing libnymphcast, compiling NymphCast Server was easy enough, after changing a few preprocessor macros to append Haiku to the FreeBSD sections, as Haiku’s file stat handling is 64-bit clean, unlike Linux, ergo it has no separate lstat64 as in Linux.

I had to update the setup.sh script in NymphCast’s root folder to check for Haiku (using the output from uname -s) and install the appropriate dependencies, matching the list of dependencies that I was using already for the various flavours of Linux, FreeBSD, MSYS2, etc. One long-ish compile session (using a single core in a VirtualBox VM) later, I had a fresh Haiku build of NymphCast Server (NCS). Of note here is however that unlike Linux, BSD, etc. to use network sockets, you do have to link with -lnetwork. This too was rather poorly documented in my experience.

One confusing issue after this was that having the NymphRPC and libnymphcast shared libraries in the development lib folder was not enough to run the binary on the Beta 5-development VM, but required me to copy them also into /boot/system/non-packaged/lib, which feels somewhat double. I’m not sure that this is intended behaviour.

Perhaps ironically, the last two issues I ran into while executing the NCS binary weren’t necessarily due to Haiku. Both effectively came down to my handling of IPv6 addresses, such as in the NyanSD service discovery component [6] where a logic bug existed that only showed itself when ran on a system with limited IPv6 functionality (no local IPv6 address on Haiku yet, only the loopback).

The other IPv6-related issue was my use of Poco::Net::ServerSocket::bind6() in NymphRPC, that tries to set an IPv6-related socket option that Haiku does not support. Replacing this with the bind() alternative finally got the binary to run and not keel over. After putting the network interface of the VM into bridging mode, I was able to find it using NyanSD in the NymphCast Player app on my Android phone and play back a few multimedia files.

For those who are interested, the text file with Haiku porting notes are in the NymphCast document folder [7]. With the porting complete for now, I’ll probably be looking at creating HPKGs out of NymphRPC, libnymphcast and NymphCast Server (and likely Player) next. With Haiku lacking a lot of video acceleration features, it remains to be seen how useful it will be for playback, but as a supported platform I do think that it has a lot of potential.

[1] https://github.com/MayaPosch/NymphCast
[2] https://discuss.haiku-os.org/t/solved-gcc-cannot-use-include-paths-provided-by-pkg-config/14494
[3] https://github.com/MayaPosch/NymphRPC
[4] https://mastodon.social/@waddlesplash/111767072256293340
[5] https://github.com/MayaPosch/libnymphcast
[6] https://github.com/MayaPosch/NyanSD
[7] https://github.com/MayaPosch/NymphCast/blob/master/doc/haiku_build_notes.txt