#1 Fix freetype-config by dropping patch4
Closed a month ago by rjones. Opened 2 months ago by ferdnyc.
rpms/ ferdnyc/mingw-freetype patch1  into  master

file modified
+8 -3

@@ -2,7 +2,7 @@ 


  Name:           mingw-freetype

  Version:        2.9.1

- Release:        2%{?dist}

+ Release:        3%{?dist}

  Summary:        Free and portable font rendering engine


  License:        FTL or GPLv2+

@@ -18,7 +18,7 @@ 

  # Enable additional demos

  #Patch2:        freetype-2.5.2-more-demos.patch

  Patch3:         freetype-2.6.5-libtool.patch

- Patch4:         freetype-2.8-multilib.patch

+ #Patch4:         freetype-2.8-multilib.patch

  Patch5:         freetype-2.9-ftsmooth.patch


  BuildArch:      noarch

@@ -85,9 +85,11 @@ 



  %patch3 -p1 -b .libtool

- %patch4 -p1 -b .multilib

  %patch5 -p1 -b .ftsmooth


+ # Not sure what the intent of this patch was, but it

+ # breaks freetype-config. See rhbz#1719095

+ #%patch4 -p1 -b .multilib



  %mingw_configure \

@@ -145,6 +147,9 @@ 




+ * Thu Jun 20 2019 FeRD (Frank Dana) <ferdnyc@gmail.com> - 2.9.1-3

+ - Drop patch which was breaking freetype-config (rhbz#1719095)


  * Fri Feb 01 2019 Fedora Release Engineering <releng@fedoraproject.org> - 2.9.1-2

  - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild


Drop (corrected:)freetype-2.8-multilib.patch, which causes bad paths to be output by the MinGW versions of freetype-config. See rhbz#1719095

No idea what the original intent of the patch was, but everything seems to work fine without it, and they definitely work wrong with it.

Sorry, correction: drop freetype-2.8-multilib.patch. That's the one that was messing up /usr/x86_64-w64-mingw32/sys-root/mingw/bin/freetype-config

The patch is required to avoid multilib from breaking. Specifically to avoid different versions of the freetype-config script from being generated on i686 and x86-64. So while maybe this change is broken, removing the patch is not the answer.

Pull-Request has been closed by rjones

a month ago

Don't we want different versions of the freetype-config script to be generated on i686 and x86_64 in this case, since they install into different places? The 32-bit version goes to /usr/i686-w64-mingw32/sys-root/mingw/bin/freetype-config. The 64-bit version is /usr/x86_64-w64-mingw32/sys-root/mingw/bin/freetype-config.

Quite probably, but we can't do that with the script as written because it will produce different versions of the script on different architectures. See: https://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks

I kind of feel like the whole problem is that the scripts are being made to output the same (wrong) information, when they should be outputting different information, since with MinGW libs the paths are separated.

These packages (mingw32-freetype and mingw64-freetype) built with that patch removed:

$ /usr/i686-w64-mingw32/sys-root/mingw/bin/freetype-config --cflags

$ /usr/i686-w64-mingw32/sys-root/mingw/bin/freetype-config --libs
-L/usr/i686-w64-mingw32/sys-root/mingw/lib -lfreetype

$ /usr/x86_64-w64-mingw32/sys-root/mingw/bin/freetype-config --cflags

$ /usr/x86_64-w64-mingw32/sys-root/mingw/bin/freetype-config --libs  
-L/usr/x86_64-w64-mingw32/sys-root/mingw/lib -lfreetype

...That's all correct.

But, after downgrading to mingw32-freetype-2.9.1-2.fc30.noarch and mingw64-freetype-2.9.1-2.fc30.noarch from Fedora:

$ /usr/i686-w64-mingw32/sys-root/mingw/bin/freetype-config --cflags
-I/usr/include/freetype2 -I/usr/include/libpng16

$ /usr/i686-w64-mingw32/sys-root/mingw/bin/freetype-config --libs  

$ /usr/x86_64-w64-mingw32/sys-root/mingw/bin/freetype-config --cflags
-I/usr/include/freetype2 -I/usr/include/libpng16

$ /usr/x86_64-w64-mingw32/sys-root/mingw/bin/freetype-config --libs  

...That's all wrong.

I'd suggest asking for packager help for this problem, see:


There are plenty of people on the mailing list who can advise about the best way to solve multilib issues, and continuing the conversation here isn't visible to any of them.

Thanks, will do. Because, quoting from that MultilibTricks doc you linked:

"Another way to handle those conflicts could be to have a different directory for each architecture, even for executables, enabling Fedora to be multiarch and not only multilib."

Which strikes me as exactly the MinGW situation, removing the need for multilib adjustments.