Bundling Jack apps

Bundling Jack apps in a way that they can also run on systems without Jack can be tricky.

This page is a work in progress, and any help is appreciated.

@tim-janik writes on IRC:

https://github.com/tim-janik/beast is a DAW. And i have recently merged a jack driver into our AppImage, which was... interesting. The audio core now tries to load an .so driver file, and that links against libjack. libjack is not packaged in the AppImage, so either the runtime linker manages to load the .so by linking against libjack, or it fails, and our driver loading fails, and we can still use ALSA. so it works. mind you, we still need to fallback even if the driver is loaded and libjack is present but jackd is not running, so all in a multi-step process of trying to get jack output going and if not fallback gracefully.

It looks like the MuseScore AppImage also supports libjack, they added active detection code: https://musescore.org/en/node/292473

ld links your .o objects into a binary, static lib .a or dynamic lib .so. ldd shows what the dynamic library linker ld.so loads at binary startup time (or when an .so is loaded later on with dlopen()). During binary startup time, missing .so dependencies are fatal, the binary cannot run. during dlopen(), the call will just fail and the process may handle the missing module gracefully. ldconfig builds a cache file that contains entries for all the dynamic libraries that ld.so may need.

ldconfig is needed for runtime linking, not compile time

so for bundling applications that need libjack, all the code that makes use of libjack symbols needs to be moved into an .so module, which is dlopen()-ed after the application has started. and errors need to be handled gracefully, e.g. by falling back to pulseaudio or ALSA.

that's all obvious in my head but probably not for everyone else, maybe pasting this conversation into the wiki page you suggested is a start ;-)