AppImageCommunity
Blacklist libharfbuzz.so.*
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
But then, whenever we (must?) bundle libgtk-3.so.0 then seemingly we also must bundle this, in order not to run into this...
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.
I don't know a) where this error comes from and b) how to solve it best. Maybe ask the HarfBuzz team?
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.
Either bundle both libharfbuzz and libpangoft2 (and probably other pango libraries) or neither of them.
@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.
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 https://github.com/probonopd/AppImages/issues/240 pointed in excludlist is a dead link. I need to know details of that case.
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.
But https://github.com/probonopd/AppImages/issues/240 pointed in excludlist is a dead link. I need to know details of that case.
https://github.com/AppImage/AppImages/issues/240
Also check the comments in https://github.com/AppImage/AppImages/blob/master/excludelist
Seems like rpcs3 no longer uses pango at all and I'm really lazy about building the AppImage of fallible version myself.
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
FT_Get_Var_Blend_Coordinates
FT is a hint it's related to pangoft2.
Feel free to send a PR blacklisting both pangoft2 and harfbuzz in the AppImages repository. We really should push a fix now.
https://github.com/AppImage/AppImageKit/issues/454#issuecomment-342213583 and https://github.com/AppImage/AppImageKit/issues/454#issuecomment-342235269.
@Calinou please remove libharfbuzz, libpangoft2 and libfreetype from your AppImage and retry. Does the issue go away, and does the AppImage still work?
Once I remove libharfbuzz and libfreetype (there's no libpangoft2 in my AppImage), it runs but it looks ugly (the system theme isn't used, which isn't the case with a dynamically-linked build from an Ubuntu 16.04 container). I can see those warnings in the console:
(AppRun:5826): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libpixmap.so: wrong ELF class: ELFCLASS32
(AppRun:5826): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libpixmap.so: wrong ELF class: ELFCLASS32
(AppRun:5826): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libpixmap.so: wrong ELF class: ELFCLASS32
(AppRun:5826): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libpixmap.so: wrong ELF class: ELFCLASS32
(AppRun:5826): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libpixmap.so: wrong ELF class: ELFCLASS32
(AppRun:5826): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita",
@Calinou can you try to bundle libpangoft2 then, please? Just cp it in your build recipe.
Well, was it blacklisted?
You should transfer this issue into AppImages.
Expect to see trouble ahead with HarfBuzz again. This time they removed hb_subset_input_set_retain_gids in libharfbuzz 3.0.0 without increasing the so version, which still comes as libharfbuzz.so.0.
All Electron apps may lo longer be working if the AppImage does not bundle libharfbuzz privately and the libharfbuzz version in the system is updated to 3.0.0 or higher.
Reference: https://github.com/harfbuzz/harfbuzz/issues/3216
Update: According to https://github.com/harfbuzz/harfbuzz/issues/3216#issuecomment-947139532
The breakage you are experiencing is in the separate libharfbuzz-subset.so
So it looks like we can leave libharfbuzz.so on the excludelist as long as libharfbuzz-subset.so gets privately bundled.
Well, was it blacklisted?
Yes:
https://github.com/AppImage/pkg2appimage/blob/477590ddb3751436e24f479bfbc8b44659936b04/excludelist#L115
But if hb_subset_input_set_retain_gids turns out to become the problem I expect it to, then we may be forced to remove it from the blacklist and privately bundle it again (because apparently it is a moving target with missing symbols within the same major version).