Blacklist libharfbuzz.so.*

[probonopd]

Bundling HarfBuzz seems to cause symbol lookup error: /usr/lib64/libpangoft2-1.0.so.0: undefined symbol: hb_buffer_set_cluster_level.

rm usr/lib/libharfbuzz.* # Workaround for: csl: symbol lookup error: /usr/lib64/libpangoft2-1.0.so.0: undefined symbol: hb_buffer_set_cluster_level
Example:
https://github.com/probonopd/cubelister/blob/patch-1/.travis.yml

[probonopd]

Also in linuxdeployqt

[probonopd]

But then, whenever we (must?) bundle libgtk-3.so.0 then seemingly we also must bundle this, in order not to run into this...

[FreeSlave]

Ran into the same issue with undefined symbol hb_buffer_set_cluster_level when bundling an application using debian jessie libraries and running it on debian stretch.
I think libharfbuzz is one of the basic libraries and should be taken from the system.

[probonopd]

I don't know a) where this error comes from and b) how to solve it best. Maybe ask the HarfBuzz team?

[FreeSlave]

I think the origin of error is pretty obvious.
libharfbuzz on debian jessie does not have hb_buffer_set_cluster_level function and libpangoft2 does not reference it.
While on debian stretch libpangoft2 has a reference to hb_buffer_set_cluster_level.
So packing old libharfbuzz while not packing libpangoft2 leads to the situation when the newer libpangoft2 (the system one) is used with old libharfbuzz (the packed one), therefore symbol can't be found.

[probonopd]

So you're saying we should bundle libpangoft2-1.0-0 too?

[FreeSlave]

Either bundle both libharfbuzz and libpangoft2 (and probably other pango libraries) or neither of them.

[FreeSlave]

So what's the decision? Will you add harfbuzz to the excludelist?

[TheAssassin]

Which way do you think makes more sense, @FreeSlave?

[FreeSlave]

@TheAssassin the post above referenced another issue with gtk3 in mypaint. I did not go into details of the situation with mypaint though. libharfbuzz depends on libfreetype, so removing libfreetype from bundle may fix the issue in that particular case (if it was bundled. Again, I don't know the whole thing just from one issue) to avoid the situation when the system libharfbuzz requires some functions from libfreetype which are missing from the bundled version (which happens to be too old).
Is it ok to remove libfreetype from bundle? Because if we don't bundle libharfbuzz then we should not bundle libfreetype either (at least the old versions).
What I know for sure is what I already told. Bundling libharfbuzz cause issues when libpangoft2 is not bundled. The issue with libpangoft2 referenced in excludelist is Not Found page, so I can't say more.

[FreeSlave]

basically the libharfbuzz for libpangoft2 is the same as libfreetype for libharfbuzz.
One from the system may require symbols that may be missing in the bundled version.
So we either bundle them all or none of them. If we consider all these libraries to always present on the target system, then we may remove them from bundle.
If we do remove them from bundle there might be reverse situation though. Some lib (e.g. libgtk3) which we bundle may require some functions from the libs mentioned above which may be missing on the target system (i.e. old distro, which contain old libraries which don't have needed symbols).
So it all rests against the issue with pangoft2. But #240 pointed in excludlist is a dead link. I need to know details of that case.

[TheAssassin]

The problem is, both seem suboptimal. I tend to the "remove all conflicting libraries" option.

@probonopd I'd remove libharfbuzz, libpangoft2 and libfreetype, add a notice about them to the excludelist, and hope for the best. If there should be problems, I'm sure people will step up to us.

[probonopd]

But #240 pointed in excludlist is a dead link. I need to know details of that case.

#240

Also check the comments in https://github.com/AppImage/AppImages/blob/master/excludelist

[FreeSlave]

Seems like rpcs3 no longer uses pango at all and I'm really lazy about building the AppImage of fallible version myself.

[Calinou]

This TrenchBroom AppImage (built on Ubuntu 14.04, see build script) outputs an error when run on Fedora 27:

./TrenchBroom-x86_64.AppImage: symbol lookup error: /lib64/libharfbuzz.so.0: undefined symbol: FT_Get_Var_Blend_Coordinates