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

From: Date: Mon, 14 May 2018 20:47:15 +0000
Subject: Bug #76310 [Asn->Opn]: with-freetype-dir doesn't work with custom prefix
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-215252@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=76310&edit=1 ID: 76310 Updated by: cmb@php.net Reported by: fred5 at originsystems dot co dot za Summary: with-freetype-dir doesn't work with custom prefix -Status: Assigned +Status: Open Type: Bug Package: GD related Operating System: CentOS 7 PHP Version: 7.1.17 -Assigned To: cmb +Assigned To: Block user comment: N Private report: N New Comment: It seems to me we're merely hitting a limitation of freetype-config here, and the cleanest way to get rid of this limitation would be to switch to pkg-config (see <https://bugs.php.net/76324>). For time reasons I won't be able to have a closer look at this now, so I'm unassigning myself. A pull request would certainly be welcome. Previous Comments: ------------------------------------------------------------------------ [2018-05-14 16:33:32] fred5 at originsystems dot co dot za bump. apologies for push on this but it as configure is generated dynamically this is a a real problem for our automated build and I would greatly appreciate knowing whether this has been accepted as a real bug and whether I can expect a fix to appear. thanks ------------------------------------------------------------------------ [2018-05-10 21:53:25] cmb@php.net Related To: Bug #76324 ------------------------------------------------------------------------ [2018-05-08 13:01:33] fred5 at originsystems dot co dot za One other thing possibly worth mentioning is that I use and process a number of other PHP configure switches for custom library locations such as: --with-icu-dir --with-apxs2 --with-curl etc in exactly the same way and all work fine ie. -I[correct custom directory prefix]. freetype is the only custom built library that incorrectly reports -I/usr/include/freetype2 ------------------------------------------------------------------------ [2018-05-08 12:45:21] fred5 at originsystems dot co dot za 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 ------------------------------------------------------------------------ [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> ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=76310 -- Edit this bug report at https://bugs.php.net/bug.php?id=76310&edit=1

« previous php.bugs (#215252) next »