After a routine `emerge -avuDN world` I noticed my PHP packages (5.6, 7.0 and 7.2) failed to complete the configure phase for the same reason: ...snip... checking for FreeType 2... /usr checking whether to enable truetype string function in GD... no checking whether to enable JIS-mapped Japanese font support in GD... no If configure fails try --with-webp-dir=<DIR> checking for jpeg_read_header in -ljpeg... yes checking for png_write_image in -lpng... yes If configure fails try --with-xpm-dir=<DIR> configure: error: freetype-config not found. ...snip... I checked my freetype version and noticed it was bumped from 2.9 to 2.9.1 during my previously-mentioned world update. I didn't suspect breaking changes due to semantic versioning, but when I checked the project's website (https://sourceforge.net/projects/freetype/files/freetype2/2.9.1) I was surprised to find that it did in fact contain breaking changes: - Use of the `freetype-config' script to get compilation and linking options is deprecated since it doesn't support cross-compiling, among other deficiencies. Instead, you should use the `pkg-config' interface. The `configure' script no longer installs `freetype-config' by default. For backwards compatibility, a new configure option `--enable-freetype-config' is provided that reverts this decision. We can either enable this new configure option `--enable-freetype-config' in the freetype-2.9.1 ebuild, or perhaps this should be filed with PHP to use pkg-config instead so that the build does not fail when trying to use freetype 2.9.1, since freetype-config is deprecated after all. Other packages which are expecting the older interface might also be failing to build, however I've only experienced this with PHP thus far. I have temporarily reverted to 2.9 to fix the problem until a permanent solution is introduced.
*** Bug 654794 has been marked as a duplicate of this bug. ***
Let's turn this into a tracker bug. Packages should really use pkg-config to find freetype.
We see failing packages because you choose to set --disable-freetype-config and you have a security issue that requires this tracker to be resolved? Why can't you add USE=freetype-config, mask that for now, and resolve the blockers later?
(In reply to Jeroen Roovers from comment #3) > We see failing packages because you choose to set --disable-freetype-config Wrong. Even if I hadn't set that configure option the freetype-config file would not have been installed. This has been made an opt-in option as can be seen here: https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=a7833f26c4ac45cafe1dffdcd7f7dcfd6493161c and I chose to use this opportunity to get rid of this ancient crap.
*** Bug 654962 has been marked as a duplicate of this bug. ***
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7c6cbca69804ed1334671fc3a62feae93943dc6d commit 7c6cbca69804ed1334671fc3a62feae93943dc6d Author: Lars Wendler <polynomial-c@gentoo.org> AuthorDate: 2018-05-10 19:14:44 +0000 Commit: Lars Wendler <polynomial-c@gentoo.org> CommitDate: 2018-05-10 19:15:29 +0000 media-libs/freetype: Add back freetype-config to -r1 in order to have a sane stable candidate. Added -r2 which - again - lacks freetype-config. Bug: https://bugs.gentoo.org/654792 Package-Manager: Portage-2.3.36, Repoman-2.3.9 media-libs/freetype/freetype-2.9.1-r1.ebuild | 2 +- media-libs/freetype/freetype-2.9.1-r2.ebuild | 234 +++++++++++++++++++++++++++ 2 files changed, 235 insertions(+), 1 deletion(-)
The script is clearly stupid and over engineered (not to mention deprecated) but it does try to call pkg-config, which kinda seems like it could be worse. If and when freetype gets around to eliminating all the other projects will deal with it. Until then, I predict quasi-abandonware high-inertia projects won't budge, forcing half of the maintainers of the above ebuilds to carry a bunch of autocruft, and forcing end-users to implement overlays or /etc/portage/env hacks to revert this (which happens to be how I spent the last hour or so, hence my coming here to bitch and moan...) In your opinion, is there reason to believe freetype-config removal is imminent? Or will it more likely take years or even conceivably outlive freetype entirely? You likely know better than I... If the former, OK. But if the latter, why not just set MULTILIB_CHOST_TOOLS=(/usr/bin/freetype-config) Instead of drop? It's purpose built gentoo automagic for exactly these foo-config hassles and should really work OK for cross-compiles, multilib, what-have-you, after all...
(In reply to Lars Wendler (Polynomial-C) from comment #4) > (In reply to Jeroen Roovers from comment #3) > > We see failing packages because you choose to set --disable-freetype-config > > Wrong. Even if I hadn't set that configure option the freetype-config file > would not have been installed. Actually, that's only partially wrong. If you change 'dis' to 'en' in that line of the ebuild, freetype-config will get build and installed. That's all I had to do to get netsurf to build. I second the motion for a USE flag, until we still have ebuild that fail due to freetype-config missing.
