Package Details: mingw-w64-fontconfig 2.13.92-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: 15
Popularity: 0.006442
First Submitted: 2012-09-05 17:59
Last Updated: 2020-05-20 03:10

Latest Comments

« First ‹ Previous 1 2 3 Next › Last »

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.

ant32 commented on 2013-11-06 17:01

Fedora uses win-iconv http://pkgs.fedoraproject.org/cgit/?q=mingw-&ofs=150. I think we should only use one or the other as a default for all packages. Also win-iconv does not provide libiconv. Applicactions built with win-iconv link to iconv.dll and applications built with libiconv link to libiconv-2.dll. Renaming the dlls does not work either.

xantares commented on 2013-11-06 16:19

Hi,

Is there any reason to depend on win-iconv rather than libiconv ?

There's the same question for mingw-w64-qt4,
should we change also all the packages that depend on libiconv ?

xan.