Red Hat Bugzilla – Bug 961855
Latest freetype build has broken headers, causing other packages to fail to build
Last modified: 2013-09-25 07:23:04 EDT
From config.log from a local rawhide mockbuild of ClanLib:
configure:15940: g++ -o conftest -I"/usr/include"/freetype2 -I"/usr/include"
In file included from conftest.cpp:64:0:
/usr/include/ft2build.h:56:38: fatal error: freetype/config/ftheader.h: No such
Thank you for reporting this. The problem is that there are quotes in values of freetype's variables in freetype2.pc file.
I'm working on fix.
I've committed a fix for this bug. It should be fixed in freetype-2.4.12-2.fc20. I'll file an upstream bug for this and will recheck the "multilib" patch yet (reverting it helps too).
(In reply to comment #2)
> I've committed a fix for this bug. It should be fixed in
I've just rebuild ClanLib in rawhide, and now its display parts (which depend on freetype) are enabled by configure again, so it sure looks fixed, closing.
How comes that there are problems with quotes? IIRC, there is even a test file in the pkg-config source code bundle which handles quotes.
I've just tested (again) with pkg-config version 0.26, and something like
pkg-config --cflags freetype2
using the freetype2.pc file from FreeType 2.4.12.
Is it possible that you are parsing the .pc files by yourself, skipping pkg-config?
From what I understand, Fedora patches the headers a bit to enable "multilib", ie, both 32bit and 64bit versions of the library using the same includes. I think the typo was in one of the Fedora patches, not in FreeType per se.
(In reply to comment #4)
> How comes that there are problems with quotes? IIRC, there is even a test
> file in the pkg-config source code bundle which handles quotes.
> I've just tested (again) with pkg-config version 0.26, and something like
> pkg-config --cflags freetype2
> properly returns
> -I/usr/local/include/freetype2 -I/usr/local/include
> using the freetype2.pc file from FreeType 2.4.12.
> Is it possible that you are parsing the .pc files by yourself, skipping
the problem is not with the quotes in freetype's .pc file at the end. I haven't much time to find a proper fix for this yet but here is some info.
According to https://bugs.freedesktop.org/show_bug.cgi?id=3571, pkgconfig should handle quotes well. As I didn't find this before, I thought that the quotes shouldn't be there.
Because of the multilib fix (which I have to find what exactly it fixes) the quotes are propagated into freetype-config through "pkg-config --variable=..." which returns value of the variable together with quotes. Concatenating this with a relative path returns a path which fails the build of ClanLib ( -I"/usr/include"/freetype2 in this case). I have to find whether it is correct that pkg-config returns the value together with quotes.
The best solution to this would be to remove the multilib patch but I have to find whether the problem is gone are how to fix it another way. The current "fix" works for now, so I'll keep it there yet.
Yeah, it looks fishy that quotes are returned for the `--variable' argument. However, it's rather straightforward to work around this in scripts: assign the output of `--variable' to a shell variable which gets re-interpreted by `eval'.
(In reply to comment #6)
> Because of the multilib fix (which I have to find what exactly it fixes)
I've not looked, but usually multilib fixes are to allow one to install ie both freetype-devel.i686 and freetype-devel.x86_64 on the same system. I guess the patch modifies /usr/bin/freetype-config to use pkgconfig instead of hardcoded values set by ./configure? If so then this is done so that the contents of /usr/bin/freetype-config is identical on i686 and x86_64, otherwise the 2 -devel packages will conflict.
I have an update on this. I've filed a bug about not unquoting of returned values of variables by pkg-config. Upstream of pkg-config accepted my patch so the actual master unquotes returned values now (see https://bugs.freedesktop.org/show_bug.cgi?id=67904).
I'll remove my patch from freetype once the pkg-config's patch gets into Fedora.