https://bugs.winehq.org/show_bug.cgi?id=41758
Bug ID: 41758 Summary: wine can't load freetype if the latter is built with harfbuzz support Product: Wine Version: 1.9.23 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdi32 Assignee: wine-bugs@winehq.org Reporter: bero@lindev.ch Distribution: ---
Created attachment 56202 --> https://bugs.winehq.org/attachment.cgi?id=56202 Proposed workaround
If freetype (tried freetype 2.7, wine 1.9.23; probably also valid for other versions) is built with harfbuzz support, wine complains about:
Wine cannot find the FreeType font library. To enable Wine to use TrueType fonts please install a version of FreeType greater than or equal to 2.0.5.
Adding some debug statements, it turns out that wine_dlopen fails not because the library isn't there, but because dlopen barfs because it can't resolve hb_ft_font_create in libfreetype.so.6. (Same for libfontconfig.so.1).
A fix (workaround?) is to use RTLD_LAZY instead of RTLD_NOW when dlopening freetype and fontconfig -- seems to work well after that.
Patch relative to wine-staging 1.9.23 attached.
https://bugs.winehq.org/show_bug.cgi?id=41758
--- Comment #1 from Nikolay Sivov bunglehead@gmail.com --- So the actual problem is that harfbuzz (potentially 32bit build of it) is not installed on your system? I think it's better to fail right away than to let it die in some obscure way when hb_* calls are supposed to be made.
https://bugs.winehq.org/show_bug.cgi?id=41758
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|gdi32 |-unknown
https://bugs.winehq.org/show_bug.cgi?id=41758
--- Comment #2 from Bernhard Rosenkränzer bero@lindev.ch --- No, the 32bit version of harfbuzz is there and where it belongs, and freetype is linked to it too
[bero@desktop ~]$ ldd /usr/lib/libfreetype.so.6 linux-gate.so.1 (0xf775f000) libz.so.1 => /lib/libz.so.1 (0xf769c000) libbz2.so.1 => /lib/libbz2.so.1 (0xf768b000) libpng16.so.16 => /usr/lib/libpng16.so.16 (0xf7654000) libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0 (0xf75da000) libc.so.6 => /lib/libc.so.6 (0xf74a3000) libm.so.6 => /lib/libm.so.6 (0xf7459000) libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0xf7353000) libgraphite2.so.3 => /usr/lib/libgraphite2.so.3 (0xf732b000) /lib/ld-linux.so.2 (0x56645000) libpcre.so.1 => /lib/libpcre.so.1 (0xf72bc000) libpthread.so.0 => /lib/libpthread.so.0 (0xf72a3000) [bero@desktop ~]$ file /usr/lib/libharfbuzz.so.0 /usr/lib/libharfbuzz.so.0: symbolic link to libharfbuzz.so.0.10303.0 [bero@desktop ~]$ file /usr/lib/libharfbuzz.so.0.10303.0 /usr/lib/libharfbuzz.so.0.10303.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=e2ad3308523143411340a5b7534172da3651c4b9, stripped
I haven't figured out why hb_ft_font_create remains unresolved despite this so far (weird load order issue?). I do know that dlerror() says hb_ft_font_create is the issue. (Btw, the use of dlerror in wine is rather odd, will file another bug report for that)
https://bugs.winehq.org/show_bug.cgi?id=41758
--- Comment #3 from Nikolay Sivov bunglehead@gmail.com --- I see. Maybe the problem comes from circular dependency - harfbuzz itself depends on freetype, and it's a hard dependency I think. Freetype dependency on harfbuzz is optional. In order to build so they both depend on each other you'll have to build freetype without hb support, then harfbuzz linking to this newly built freetype and then freetype itself with hb support enabled. Easy solution would be to make freetype dynamically load harfbuzz when needed, not sure if something like will be accepted or even considered.
https://bugs.winehq.org/show_bug.cgi?id=41758
Dave-C davec.bugs@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |davec.bugs@gmail.com