This is related to bug #76310 – at least I presume that issue
would be resolved by switching to pkg-config.  I've practically no
experience with pkg-config, so a patch or preferably a pull
request would be welcome.  I'm not sure which PHP version to
target; 5.6 and 7.0 are for security fixes only, and to avoid
issues with stable versions (7.1 and 7.2) it might be best to
target master only.

Yes, it would. Users with a custom freetype directory would simply set the environment variable PKG_CONFIG_PATH=/path/to/custom/freetype/pkgconfig/ to seamlessly override everything.

Which version to target? Well, the question is do you want to fix maintenance versions of php fatally failing to find the requested freetype, on newer systems. Yes, people do run maintenance versions of php even on bleeding-edge distros. This isn't something likely to fail, unless a system simply doesn't have pkg-config.



So I'm actually looking at what it would take to do this, but I think it would be simplest to just use standard tools like https://autotools.io/pkgconfig/pkg_check_modules.html

The entire freetype check could be replaced by:

PKG_CHECK_MODULES([FREETYPE2], [freetype2], [FREETYPE2_FOUND=true], FREETYPE2_FOUND=false)

PKG_CHECK_MODULES handles setting FREETYPE2_LIBS/FREETYPE2_CFLAGS, then lets you set custom success/failure handlers, by default simply aborting when freetype2 is missing, in this case just setting the FREETYPE2_FOUND variable.

Currently this doesn't find the pkg.m4 macro from the systemwide pkg-config installation, which probably has something to do with the nonstandard acinclude.m4, buildconf setup as opposed to autoreconf.

Just uploaded a patch which vendors in the pkg-config macros just like a couple autoconf-archive blobs, and uses pkg-config to detect freetype2 support.

@eshwartz - thanks for making the patch! I've tried applying it to a PHP 7.2.7 source folder as follows:

patch < 0001-ext-gd-Use-pkg-config-to-detect-the-availability-of-freetype.patch 

and it partially succeeds but sadly also returns some errors.

I'm not sure if I'm doing something wrong so would greatly appreciate any feedback. Thanks!

==================================================================
Output when running against 7.1.18 PHP source tree
==================================================================

patching file acinclude.m4
Hunk #9 succeeded at 889 (offset 4 lines).
Hunk #10 succeeded at 946 (offset 4 lines).
Hunk #11 succeeded at 999 (offset 11 lines).
Hunk #12 succeeded at 1029 (offset 11 lines).
Hunk #13 succeeded at 1191 (offset 11 lines).
Hunk #14 succeeded at 1256 (offset 11 lines).
Hunk #15 succeeded at 1293 (offset 11 lines).
Hunk #16 succeeded at 1315 (offset 11 lines).
Hunk #17 succeeded at 1353 (offset 11 lines).
Hunk #18 succeeded at 1374 (offset 11 lines).
Hunk #19 succeeded at 1411 (offset 11 lines).
Hunk #20 succeeded at 1514 (offset 11 lines).
Hunk #21 succeeded at 1522 (offset 11 lines).
Hunk #22 succeeded at 1629 (offset 11 lines).
Hunk #23 succeeded at 1670 (offset 11 lines).
Hunk #24 succeeded at 1716 (offset 11 lines).
Hunk #25 succeeded at 1810 (offset 11 lines).
Hunk #26 succeeded at 1847 (offset 11 lines).
Hunk #27 succeeded at 1937 (offset 11 lines).
Hunk #28 succeeded at 2012 (offset 11 lines).
Hunk #29 succeeded at 2082 (offset 11 lines).
Hunk #30 succeeded at 2119 (offset 11 lines).
Hunk #31 succeeded at 2149 (offset 11 lines).
Hunk #32 succeeded at 2183 (offset 11 lines).
Hunk #33 succeeded at 2312 (offset 5 lines).
Hunk #34 succeeded at 2359 (offset 5 lines).
Hunk #35 succeeded at 2398 (offset 5 lines).
Hunk #36 succeeded at 2433 (offset 5 lines).
Hunk #37 succeeded at 2497 (offset 5 lines).
Hunk #38 succeeded at 2531 (offset 5 lines).
Hunk #39 succeeded at 2613 (offset 5 lines).
Hunk #40 succeeded at 2624 (offset 5 lines).
Hunk #41 succeeded at 2632 (offset 5 lines).
Hunk #42 succeeded at 2655 (offset 5 lines).
Hunk #43 succeeded at 2717 (offset 5 lines).
Hunk #44 succeeded at 2785 (offset 5 lines).
Hunk #45 succeeded at 2867 (offset 5 lines).
Hunk #46 succeeded at 2877 (offset 5 lines).
Hunk #47 succeeded at 2889 (offset 5 lines).
Hunk #48 FAILED at 3317.
1 out of 48 hunks FAILED -- saving rejects to file acinclude.m4.rej
patching file pkg.m4
can't find file to patch at input line 775
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/configure.ac b/configure.ac
|index e18e1de2ef..655e06837b 100644
|--- a/configure.ac
|+++ b/configure.ac
--------------------------
File to patch: 

==================================================================
Output when running against 7.2.7 PHP source tree
==================================================================
patching file acinclude.m4
Hunk #33 succeeded at 2301 (offset -6 lines).
Hunk #34 succeeded at 2348 (offset -6 lines).
Hunk #35 succeeded at 2387 (offset -6 lines).
Hunk #36 succeeded at 2422 (offset -6 lines).
Hunk #37 succeeded at 2486 (offset -6 lines).
Hunk #38 succeeded at 2520 (offset -6 lines).
Hunk #39 succeeded at 2602 (offset -6 lines).
Hunk #40 succeeded at 2613 (offset -6 lines).
Hunk #41 succeeded at 2621 (offset -6 lines).
Hunk #42 succeeded at 2644 (offset -6 lines).
Hunk #43 succeeded at 2706 (offset -6 lines).
Hunk #44 succeeded at 2774 (offset -6 lines).
Hunk #45 succeeded at 2856 (offset -6 lines).
Hunk #46 succeeded at 2866 (offset -6 lines).
Hunk #47 succeeded at 2878 (offset -6 lines).
Hunk #48 FAILED at 3317.
1 out of 48 hunks FAILED -- saving rejects to file acinclude.m4.rej
patching file pkg.m4
patching file configure.ac
Hunk #3 succeeded at 689 (offset -17 lines).
Hunk #4 succeeded at 711 (offset -17 lines).
Hunk #5 succeeded at 798 (offset -31 lines).
Hunk #6 succeeded at 808 (offset -31 lines).
Hunk #7 succeeded at 841 (offset -31 lines).
Hunk #8 succeeded at 931 (offset -31 lines).
Hunk #9 succeeded at 1029 (offset -31 lines).
Hunk #10 succeeded at 1116 (offset -31 lines).
Hunk #11 succeeded at 1235 (offset -31 lines).
can't find file to patch at input line 884
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/ext/gd/config.m4 b/ext/gd/config.m4
|index c3ff5ece24..2a9d8e3570 100644
|--- a/ext/gd/config.m4
|+++ b/ext/gd/config.m4
--------------------------
File to patch:

The patch was generated from git format-patch, and git am should apply it when run from a source checkout on git master.

Though actually, it does contain some whitespace changes, because my editor auto-cleans trailing whitespace when saving files... this explains the one rejected hunk in acinclude.m4 (the hunk did not matter) but does not explain how patch was unable to find some files.

Did you forget to use -p1 which is required when applying git patches (and many others) to remove the base directories used when diffing two large trees? I'm a bit confused, since patch found acinclude.m4 but not configure.ac...

I have no idea what that was...

@cmb, if you'd prefer a pull request to a patch, I can open a pull request on Github... which branch should I target? CONTRIBUTING.md suggests, since I'm fixing a bug, I should submit it to PHP-7.1 and let it be cherry-picked upwards? Or is it an RFC which should be submitted to master?

I'm used to projects where everything is always submitted to master, no matter what, and only afterward will commits be cherry-picked for older branches, so I'm not really sure what I should do here as the CONTRIBUTING.md is giving me mixed messages.

Yeah, I'd prefer a PR for visibility and mergability (I've tried
to git -am the patch, but that failed for PHP-7.1, PHP-7.2 and
master).

Regarding the target branch: if in doubt, target master – this can
still be adjusted.  In this case it might have been a good idea to
switch to pkg-config long ago (see also PR 3341[1]), so treating
this as bug fix and targeting PHP-7.1 accordingly, might be
sensible as well.

Anyway, thanks for your efforts, Eli! :)

[1] <https://github.com/php/php-src/pull/3341>

Hi Eli? :o)

At the outset I should acknowledge that I'm very unfamiliar with the patching process as have never had to do before. I opened bug #76310 because our PHP build - which has always worked perfectly - "suddenly" started applying the incorrect, older OS native freetype version 2.4.11 (instead of 2.7.1). 

I am under some pressure to get this sorted out as we need to release a new build, so have attempted to use your provided patch as follows:

1. downloaded php-7.2.7.tar.gz release from http://uk3.php.net/distributions
2. extract
3. download your patch (called 0001.patch from now on) to the extracted PHP directory
4. cd to the extracted PHP directory
5. run the command "patch < 0001.patch"   (with no switches at all)
.... got the errors shown in previous post.

I acknowledge this may be completely wrong due to my lack of knowledge and am explaining above simply to make sure the use case is clear when looking at the output. Thanks again for your help on this.

Ok, so this should be the simplest patch possible to make PHP use pkg-config for FreeType2 if pkg-config is available:

https://github.com/php/php-src/pull/3630

My apologies for forgetting about this yet again -- I've submitted https://github.com/php/php-src/pull/3632 as the original approach, which I believe is superior to ondrej's "simplest patch possible".

Note that the pkg-config program provides battle-tested autotools macros to do this in the proper, approved way. Using these macros will properly handle e.g. PKG_CONFIG='pkg-config --static' (handy when downstream builders wish to statically compile a program), which the simple patch fails on two counts -- it does not do path resolution, and it assumes the content is a possibly-whitespace-included-path, which prevents the possibility of overriding some obscure pkg-config behavior via command-line flags.

Using the pkg-config macros is also preferable, because it will add `./configure --help` hints for the PKG_CONFIG* variables available to use, and additionally it will allow using FREETYPE2_CFLAGS/FREETYPE2_LIBS to override pkg-config detection (and hint about that too).

Also https://github.com/php/php-src/commit/cf3b852109a88a11370d0207cd3b72a53b6a64c3 helped to make it easier to submit clean patches that apply. :)

This is already fixed as of PHP 7.4.0.

Could this be backported to PHP 7.3? I'm running into this on a platform where freetype got upgraded.

Backporting the pkg-config support to PHP 7.3 would require
discussion on the internals mailing[1]; feel free to suggest that
there. 

[1] <https://www.php.net/mailing-lists.php#internals>