Arch Linux User Repository

hello,

small issue: it installs invalid symlinks to the build dir:
$ ls /usr/x86_64-w64-mingw32/etc/fonts/conf.d/90-synthetic.conf -l
lrwxrwxrwx 1 root root 143 Jun 11 09:31 /usr/x86_64-w64-mingw32/etc/fonts/conf.d/90-synthetic.conf -> /tmp/yaourt-tmp-xantares/aur-mingw-w64-fontconfig/pkg/mingw-w64-fontconfig/usr/x86_64-w64-mingw32/share/fontconfig/conf.avail/90-synthetic.conf

maybe due to 0001-fix-config-linking.all.patch ?

xan

Seems like something Mono-related. Do you have your environment set to recognise EXEs as Mono executables?

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.

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.

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.

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

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

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.

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.

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.