The freetype-2.4.11-r1 (multilib) version of freetype needed to change the header install location to $libdir. For that reason, all packages which don't use pkg-config nor freetype-config fail to build ;). Could you please do a tinderbox run against the dependencies with that version? It's enough to run it the with native ABI.
Yikes you're the first person to actually ask for it via bug.. But sure, getting ready for it now (expecting catastrophe, to be honest). Should we just re-use this bug as tracker?
(In reply to comment #1) > Yikes you're the first person to actually ask for it via bug.. > > But sure, getting ready for it now (expecting catastrophe, to be honest). > Should we just re-use this bug as tracker? Yes.
have you filed a bug about this upstream?
https://savannah.nongnu.org/bugs/?38235 http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=bcca86af30967d7d93590f2241b84d02f083d54e
@Michał: I am not sure if $libdir such a good idea, couldn't we automatically merge the include files: - install to DESTDIR=${ED}_${ABI} - if headers differ #if __x86_64__ content of 64bit header #else content of 32bit header #endif - do that for each header
As I told Paul who suggested that on my blog. Please don't. I remember when glibc did that — it was a mess to deal with. Some packages do NOT like the indirection and fail even more badly than they do right now.
How is this headers problem handled in portage-multilib? I saw a long discussion between mgorny and tommy on IRC but didn't see concrete solutions to this problem :(
(In reply to comment #7) > How is this headers problem handled in portage-multilib? I saw a long > discussion between mgorny and tommy on IRC but didn't see concrete solutions > to this problem :( They are doing exactly the header solution -- move the headers and install wrappers. I'm a bit afraid I will have to do that as well for freetype, or just fix the header to use proper types. The major problem is that CMake is a mess with its weird wannabe logic, and I'm afraid it can't handle things like header dependencies correctly. As in, the default macros do some weird lookup logic for headers and use pkg-config includes as hints only. For example, libXft (from X11) requires freetype2, and has proper pkg-config file. If you use pkg-config to obtain cflags for xft, you get all includedirs. However, CMake will most likely just be happy with the directory in which libXft headers sit and the build will fail because of missing freetype2 header. I would like to note, however, that this is just a theory. CMake is a mess, and its X11 module is 500 lines of random header & library lookup magic. I'm afraid that adding pkg-config support there will add at least another 250 to that, and it may not help at all.
Due to the issue count, we've decided to move the headers back. Therefore, feel free not to fix the Gentoo packages to use pkg-config or freetype-config. However, it is still preferable to at least file bugs to upstreams which aren't aware of freetype providing both the fore-mentioned interfaces.
Upstream doesn't care, most of downstream doesn't care, closing this one. Leaving just the Xft one which is against upstream policy.
