Bug #76310 [Asn->Opn]: with-freetype-dir doesn't work with custom prefix
| From: | cmb@php.net | 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