Bug #76310 [Fbk->Asn]: with-freetype-dir doesn't work with custom prefix

Edit report at https://bugs.php.net/bug.php?id=76310&edit=1 ID: 76310 User updated by: fred5 at originsystems dot co dot za Reported by: fred5 at originsystems dot co dot za Summary: with-freetype-dir doesn't work with custom prefix -Status: Feedback +Status: Assigned Type: Bug Package: GD related Operating System: CentOS 7 PHP Version: 7.1.17 Assigned To: cmb Block user comment: N Private report: N New Comment: As you say, that is the behaviour one would expect but ...sadly not. My apologies, I neglected to include the full path to freetype-config when I opened the post so I have expanded here. And three important additional notes: 1. [custom directory] is NOT /usr in my environment, it is very different 2. My build scripts as I have them have worked fine up to and including the last build I did at PHP 7.1.8 3. This build is the first time I have come across the requirement to include the --enable-freetype-config configure switch in the freetype build Now back to the issue; If one runs: [custom directory]/bin/freetype-config --cflags The output is: -I/usr/include/freetype2 ...which is not what I would expect. However, if one runs: [custom directory]/bin/freetype-config --prefix=[custom directory] --cflags then the output is: -I[custom directory]/include/freetype2 ...which is what I expect and what I need. Looking at the man page https://www.mankier.com/1/freetype-config it says: --cflags Return compiler flags for compiling against the installed FreeType library. In my case, the "installed" FreeType - ie. that which is active as part of the OS is /usr/include so freetype-config is possibly behaving as expected returning /usr/include - however it is certainly not what I expect when including --with-freetype-dir Previous Comments: ------------------------------------------------------------------------ [2018-05-08 10:44:11] cmb@php.net FTR: this bug is not related to <https://bugs.php.net/bug.php?id=73592>. > executes the statement FREETYPE2_CFLAGS=freetype-config > --cflags Hmm, that is not supposed to happen. Looking at the code[1] is should rather be: [custom directory]/bin/freetype-config --cflags Wouldn't that give the appropriate flags? [1] <https://github.com/php/php-src/blob/PHP-7.1.17/ext/gd/config.m4#L192-L207> ------------------------------------------------------------------------ [2017-01-16 01:23:13] stas@php.net Related To: Bug #73592 ------------------------------------------------------------------------ [2016-11-27 14:13:41] kalle@php.net Related To: Bug #73592 ------------------------------------------------------------------------ [2018-05-08 07:29:26] fred5 at originsystems dot co dot za Description: ------------ I build freetype in a custom location for my PHP build ie. [custom directory]. (which is of course completely unrelated to the freetype version currently running on my CentOS build server) To make sure PHP uses my [custom directory] build, I include: --with-freetype-dir=[custom directory] On build, the PHP configure script does the following: 1. correctly locates the freetype [custom directory] 2. checks that [custom directory]/bin includes freetype-config 3. executes the statement FREETYPE2_CFLAGS=freetype-config --cflags The above all looks fine ...except that step 3 completely ignores [custom directory] and incorrectly results in FREETYPE2_CFLAGS="-I/usr/include" (when it shoudl actually be set as follows FREETYPE2_CFLAGS="-I[custom directory]/include") The statement required in the configure executable that would correct this problem is FREETYPE2_CFLAGS=freetype-config --cflags --prefix=[custom directory] as it tells freetype-config to use the [custom directory] as prefix when looking for the includes folder. The current setup is a real problem as it breaks my build. Test script: --------------- There is no test script possible as this is part of the build process. I do not feel qualified to create a patch for it ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=76310&edit=1