Trying vcpkg

Developing C and C++ projects in a cross-platform manner is not only difficult because of different system APIs but also because dependencies have to be tracked, installed and integrated into the build system du jour. While it is largely a solved problem on Linux thanks to system package managers and de facto standards such as pkg-config, the situation on Windows is tricky because both are missing. Rust and Go easily circumvent this situation by building static binaries from source using their integrated package managers. In a similar manner a Microsoft team tries to combine package management and build integration on Linux, Mac and Windows with their open source vcpkg package manager.

The main idea is simple: 1) provide a repository with build and dependency descriptions for a wide range of libraries, 2) a CLI tool to actually build said libraries locally and 3) means to make use of these libraries. Each of these points has its pros and cons you can see when trying to build the following C toy example on Linux which depends on the GLib utility library:

#include <glib.h>

main (int argc, char *argv[])
    g_print ("Hello world\n");
    return 0;

With vcpkg you first have to clone the repository and then build the vcpkg binary. Easier said than done because the binary requires g++-7 to build. You then use

vcpkg install glib

to build GLib and all its dependencies which works well but has one big caveat: Using so-called CONTROL files, maintainers specify the version of the library and all their dependencies. Unfortunately, build dependencies are not versioned but taken from the current state of the repository. This means you can only pin the version of library A by not upgrading the repository therefore you are unable to upgrade to a newer version of library B. In the end, vcpkg is just like a system package manager and we are nowhere near closer to the Rust build story.

Now, how do we use our library? Well there’s the first problem. At the moment, the only officially supported way is to write a CMake build script such as this

cmake_minimum_required(VERSION 3.0)

find_path(GLIB_INCLUDE_DIR glib.h)
find_library(GLIB glib REQUIRED)

add_executable(hello hello.c)
target_link_libraries(hello PRIVATE ${GLIB_LIBRARY})
target_include_directories(hello ${GLIB_INCLUDE_DIR})

and passing their toolchain file to the configure process of CMake

cmake <builddir> . -DCMAKE_TOOLCHAIN_FILE=<vcpkgroot>/scripts/buildsystems/vcpkg.cmake

For projects that have native CMake support you can use the find_package command but as you can see we have to rely on the find_library and find_path commands for GLib. Except, it does not work. CMake is unable to find neither GLib sqlite3 using find_package as outlined in the documentation. Could we at least build something by hand? Kind of. All libraries and header files are installed under <vcpkgroot>/installed/x64-linux and the various sub-directories. However, you have to hardcode the paths because pkg-config files are not installed thus its worse than using system development libraries.

Because of these issues, I would not consider vcpkg to be an alternative package and build manager for Linux at the time of writing. There are some good ideas but spack pretty much does the same for a while now and they gave way more time thinking into their product. Let’s hope it will get better.

Using a Focusrite 18i8 under Linux

Focusrite’s Scarlett USB audio interfaces are cost-effective units with a wide range of input and output options. Out of the box they can be used by most digital audio workstations on Linux because they are USB class-compliant. However, besides the entry-level models (Solo, 2i2 and 2i4), you will certainly miss a few features for recording that just cannot be accessed due to a lack hardware controls. For these you need to use the Focusrite Control software which – as you can imagine – is available only for Mac and Windows. Fortunately, there is a device specific ALSA driver for the Scarlett devices that exposes mix controls to set gains on the different ins and outs as well as controls to enable Hi-Z or Pad modes on certain inputs. Unfortunately, using alsamixer to set these values is a huge PITA.

Now Robin Gareus, a very active contributor to Ardour, JACK and LV2 made the scarlett-mixer for his Scarlett 18i6 that allows one to control all the parameters with an easy-to-use graphical user interface. Now, I counted one and one together, made the appropriate changes and added support for the 18i8. So, no longer do I need to resort to the borderline crazy Alsa Json Gateway software 🙌

OpenCL resource tracking

I wrote about the woes I had with the abysmal OpenCL implementations by both AMD and NVIDIA. Now, it’s not always the fault of others and I recently had to debug a GPU memory leak originating from our own software. The first thing I needed to indentify was if all OpenCL resources were referenced and dereferenced equally. However, the entire system is (as usual I suppose) a dynamic pile of layers of abstractions, so simple reasoning from the code was out of the question rather quickly. I remembered the GObject tracking library from which I took the interception and backtrace bits, re-implemented the OpenCL calls dealing with resource allocation and unreferencing to make the LD_PRELOAD library Usage is similar to the GObject tracking library gobject-list:

$ LD_PRELOAD=/path/to/ ./app

with an example output like (now):

OpenCL objects alive
Contexts        1/1
Command queues  0/1
Buffers         0/9
Samplers        0/0
Kernels         3/11

Memory leaks
Leaking         0 B

Moving music content

I decided to move all music and bass related content to its own platform over at because it does not really fit the technical stuff here. No redirects were set up, so if you happened to have linked there … update your links accordingly.