Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incompatibility between AppImage's libfreetype.so.6 and system's libfontconfig.so #4280

Closed
Wallacoloo opened this issue Mar 31, 2018 · 6 comments

Comments

@Wallacoloo
Copy link
Member

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
Copy link
Member Author

Wallacoloo commented Mar 31, 2018

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
Copy link
Member

tresf commented Apr 1, 2018

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
Copy link

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

References:

@tresf
Copy link
Member

tresf commented Apr 1, 2018

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

@Wallacoloo Wallacoloo added the bug label Apr 1, 2018
@tresf tresf added the upstream label Apr 2, 2018
@tresf
Copy link
Member

tresf commented Apr 2, 2018

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
Copy link
Member Author

The new AppImage works great! 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants