Package Details: mingw-w64-fontconfig 2.16.0-1

Git Clone URL: https://aur.archlinux.org/mingw-w64-fontconfig.git (read-only, click to copy)
Package Base: mingw-w64-fontconfig
Description: A library for configuring and customizing font access (mingw-w64)
Upstream URL: https://www.freedesktop.org/wiki/Software/fontconfig/
Keywords: fontconfig mingw mingw-w64
Licenses: custom
Submitter: Schala
Maintainer: pingplug
Last Packager: pingplug
Votes: 17
Popularity: 0.000000
First Submitted: 2012-09-05 17:59 (UTC)
Last Updated: 2025-01-21 05:45 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 Next › Last »

mensinda commented on 2017-04-08 15:02 (UTC)

I have got the following compile error: make[2]: Entering directory '/home/daniel/.cache/pacaur/mingw-w64-fontconfig/src/fontconfig-2.12.1/build-i686-w64-mingw32/doc' make all-am make[3]: Entering directory '/home/daniel/.cache/pacaur/mingw-w64-fontconfig/src/fontconfig-2.12.1/build-i686-w64-mingw32/doc' GEN fclangset.sgml GEN fcmatrix.sgml GEN fcobjectset.sgml GEN fcobjecttype.sgml Cannot open assembly './edit-sgml.exe': File does not contain a valid CIL image. Cannot open assembly './edit-sgml.exe': File does not contain a valid CIL image. Cannot open assembly './edit-sgml.exe': File does not contain a valid CIL image. Cannot open assembly './edit-sgml.exe': File does not contain a valid CIL image.

J5lx commented on 2017-03-14 14:01 (UTC)

Are you sure that 0001-fix-config-linking.all.patch does what it’s supposed to do? For me it causes lots of symlinks to point inside the build directory, which it should definitely *not* do. And TBH I’m not exactly sure whether I get the purpose of the pkg-config patch either… I fail to see what it’s supposed to accomplish, and the build seems to work just fine without it (probably thanks to mingw-w64-pkg-config). Maybe the bugs these patches were supposed to fix vanished in an update? It’d be great if you could enlighten me about that.

Martchus commented on 2015-11-01 19:37 (UTC)

I've got the following errors: "configure: error: Package requirements (freetype2) were not met: Package 'bzip2', required by 'freetype2', not found" "configure: error: Package requirements (freetype2) were not met: Package 'harfbuzz', required by 'freetype2', not found" After reading the errors again, I think the dependencies should be added to mingw-w64-freetype2 and not to this package. However I'm wondering why I was able to build mingw-w64-freetype2 in the first place.

Schala commented on 2015-11-01 07:33 (UTC)

I didn't know it had those? I'm looking at native package and it has expat and freetype2

Martchus commented on 2015-10-31 17:40 (UTC)

When trying to build this in a clean chroot I missed the dependencies mingw-w64-{harfbuzz,bzip2}.

xantares commented on 2013-11-08 11:11 (UTC)

Hello, - You assume you'll have the choice, but that won't work unless he makes sure to modify and rebuild all the packages that depend on *iconv as long as the incompatibility is not solved and packages explicitely depend on win-iconv. As of today, it won't work out of the box. - But I succeeded in making win-iconv binary compatible by renaming the dll to the libiconv-2.dll as provided byt libiconv: sed -i "s|PREFIX \"\"|PREFIX \"lib\" SUFFIX \"-2.dll\" IMPORT_PREFIX \"lib\" IMPORT_SUFFIX \".dll.a\"|g" CMakeLists.txt (I tried to do that in libiconv instead first, but I'm not an autohell wizard.) Would you consider patching your PKGBUILD with this sed ? - That also mean we should convince qt5/qt4 packagers who explicitely win-iconv to go for libiconv. - Under that condition, I'll be ok to use libiconv instead. - But we could also go for the contrary: make all packages require win-iconv, and make libiconv provide win-iconv so as to build win-iconv by default, like fedora does (they do not provide libiconv though). xan.

Schala commented on 2013-11-08 01:07 (UTC)

Because as win-iconv provides libiconv (as an import lib), specifying libiconv as a dependency would allow someone who uses win-iconv to simply manually install it and that would pass as libiconv. I am unaware of any difference between the two aside from binary-incompatibility. However, my perogative is to leave binary compatibility to the package user -- do they want win-iconv, or do they want libiconv? Not everyone wants win-iconv, and not everyone wants libiconv, so I'm offering some flexibility here and I advise you do the same.

xantares commented on 2013-11-07 07:46 (UTC)

Ok, but as ant32 mentioned here it seems there's a problem with the dll name, so let's make sure we all depend on the same. Why did you switch, I just I updated gettext to use win-iconv ?!! xan.

Schala commented on 2013-11-07 03:38 (UTC)

Also, packages will link with libiconv.dll.a regardless of which you use.

« First ‹ Previous 1 2 3 Next › Last »