Package Details: mingw-w64-fontconfig 2.12.0-2

Git Clone URL: https://aur.archlinux.org/mingw-w64-fontconfig.git (read-only)
Package Base: mingw-w64-fontconfig
Description: A library for configuring and customizing font access (mingw-w64)
Upstream URL: http://www.fontconfig.org/release
Keywords: fontconfig mingw mingw-w64
Licenses: custom
Submitter: Schala
Maintainer: Schala
Last Packager: Schala
Votes: 10
Popularity: 0.740642
First Submitted: 2012-09-05 17:59
Last Updated: 2016-06-17 20:42

Latest Comments

Martchus commented on 2015-11-01 19:37

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

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

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

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.

xantares commented on 2013-11-08 10:46

Hello,

- That's more complicated than that, you assume the guy that wants win-iconv
has the choice, but that won't work unless he modifies and rebuilds in all the packages using iconv as long as the binary incompatibility is solved.

- But I succeeded in making win-iconv binary compatible by renaming the dll:
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 you PKGBUILD with this sed ?

- Under that condition, I'll be ok to use libiconv instead.

- That also mean we should convince qt5/qt4 packagers who explicitely win-iconv to go for libiconv.

- 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

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

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

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

Schala commented on 2013-11-06 21:40

I think it's a matter of preference. I'm not certain, though.

xantares commented on 2013-11-06 19:03

Ok, so I'll link my packages to win-iconv too.

All comments