Mixing system libfreetype and libharfbuzz with system libpng, bundled libpng with system libz
I think that https://github.com/AppImage/pkg2appimage/blob/master/excludelist is not very correct.
- libpng uses libz, but you suggest to use bundled libpng with system libz. BricsCAD v17 had bundled libz and used system libpng, it worked for some time but started to segfault on newer distributions
rosa-2016 ~ # readelf -a /usr/lib64/libpng16.so.16.28.0 | grep NEEDED | awk '{print $NF}'
[libz.so.1]
[libm.so.6]
[libc.so.6]
- libfreetype:
rosa-2016 ~ # readelf -a /usr/lib64/libfreetype.so.6.16.1 | grep NEEDED | awk '{print $NF}'
[libz.so.1]
[libbz2.so.1]
[libpng16.so.16]
[libharfbuzz.so.0]
[libc.so.6]
but you suggest to use it with bundled libpng and libbz2 (note that different distros have incompatible so names of libz2: some have libbz2.so.1, but some (Debian, Ubuntu) have libbz2.so.1.0)
P.S. libharfbuzz depends from libfreetype:
rosa-2016 ~ # readelf -a /usr/lib64/libharfbuzz.so.0.10704.0 | grep NEEDED | awk '{print $NF}'
[libm.so.6]
[libglib-2.0.so.0]
[libfreetype.so.6]
[libgraphite2.so.3]
[libc.so.6]
(in case of BricsCAD libz was bundled and was LD_PRELOAD'ed (seems that they did not hear about RPATH or could not use it for some reasons; after that system libpng tried to use that bundled preloaded libz)
Thanks for your report @mikhailnov.
So you suggest to remove libz.so.1 from the excludelist?
https://github.com/AppImage/pkg2appimage/blob/28429c6f30cb29854fe273c52f53b982ebcf0543/excludelist#L151
If you use system libfreetype, you must use system libpng also as far as I can imagine what is happening
So add libpng16.so.16 to the excludelist, so that it gets bundled?
probably yes, and also libpng12.so.12
Thank you for the suggestion, will do some experiments with it and in case it doesn't have negative effects, add it.
Everyone, feel free to comment.
Thank you very much.
libpng changes soname and ABI too often and there are no guarantee that libpng16 will be in the system
libpng changes soname and ABI too often and there are no guarantee that libpng16 will be in the system
Yes, this is an indication that we should indeed privately bundle it then.
Something similar happened with the old libpng12