Lmms: Incompatibility between AppImage's libfreetype.so.6 and system's libfontconfig.so

[Wallacoloo]

Found this by digging further into #4275; figured I'd open a new issue because the previous one was mostly focused on the broken GTK file chooser. The latest AppImage fails to start on Arch Linux:

$ export QT_DEBUG_PLUGINS=1
$ ./lmms-1.2.0-rc5-linux-x86_64.AppImage
[Output snipped]
Cannot load library /tmp/.mount_lmms-1DBPZbS/usr/plugins/platforms/libqxcb.so: (/usr/lib/libfontconfig.so.1: undefined symbol: FT_Done_MM_Var)
QLibraryPrivate::loadPlugin failed on "/tmp/.mount_lmms-1DBPZbS/usr/plugins/platforms/libqxcb.so" : "Cannot load library /tmp/.mount_lmms-1DBPZbS/usr/plugins/platforms/libqxcb.so: (/usr/lib/libfontconfig.so.1: undefined symbol: FT_Done_MM_Var)"
This application failed to start because it could not find or load the Qt platform plugin "xcb"
in "".

What _seems_ to be happening is this:

1. lmms dynamically loads its own libqxcb.so.
2. libqxcb loads /usr/lib/libfontconfig.so
3. /usr/lib/libfontconfig.so depends on libfreetype.so.6, but loads the lmms-packaged libfreetype.so.6 instead of the system's /usr/lib/libfreetype.so.6 because it comes first on LD_LIBRARY_PATH. This fails because the system's libfontconfig.so expects libfreetype.so.6 to export the FT_Done_MM_Var function, which is only present on more recent builds of freetype.

If I _remove_ the libfreetype.so.6 packaged in the lmms AppImage bundle, lmms loads and functions as expected.

[Wallacoloo]

I believe the simplest fix is to just package a new AppImage with an updated version of libfreetype.so (FT_Done_MM_Var was added 2018/01/06). But that doesn't prevent similar issues from arising down the road - I think the bigger issue is that we have an AppImage .SO pulling in a system .SO which in turn pulls in an AppImage .SO. Long term, we probably want to also package libfontconfig.so and its dependencies, or see what the impact is of just not packaging libfreetype.so and instead using the host's version.

Tagging @Umcaruje because I'm pretty sure you've packaged some of these AppImages before, so maybe you've some better idea of what to do here than I :)

[tresf]

Tagging @probonopd. He's the maintainer of linuxdeployqt as well as a maintainer of the AppImageKit project. I doubt we're the first to encounter this.

[probonopd]

We think that either not bundling libfreetype.so.6 and libharfbuzz.so.0 or bundling both of them should resolve this issue.

References:

• https://github.com/AppImage/AppImages/commit/9082bbe3b924b656d8675da64a69c6b2b32ac7b4
• https://github.com/probonopd/linuxdeployqt/issues/261#issuecomment-377522251
• https://github.com/probonopd/linuxdeployqt/issues/157#issuecomment-320755694

[tresf]

@probonopd thanks for the quick response. As this patch hits mainline, I assume just repackaging will do the trick.

[tresf]

Here's an AppImage created from a fresh Ubuntu box with the latest continuous linuxdeployqt version which -- I assume -- has the bleeding edge AppImageKit bundled which has since removed libfreetype.so.6 and libharfbuzz.so.0 from the library include list.

https://github.com/tresf/lmms/releases/download/v1.2.0-rc5/lmms-1.2.0-rc5.43-linux-x86_64.AppImage

[Wallacoloo]

The new AppImage works great! :tada: