php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #76310 with-freetype-dir doesn't work with custom prefix
Submitted: 2018-05-08 07:29 UTC Modified: 2021-05-22 13:12 UTC
From: fred5 at originsystems dot co dot za Assigned: krakjoe (profile)
Status: Closed Package: GD related
PHP Version: 7.1.17 OS: CentOS 7
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: fred5 at originsystems dot co dot za
New email:
PHP Version: OS:

 

 [2018-05-08 07:29 UTC] 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


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-05-08 10:44 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2018-05-08 10:44 UTC] 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>
 [2018-05-08 12:45 UTC] fred5 at originsystems dot co dot za
-Status: Feedback +Status: Assigned
 [2018-05-08 12:45 UTC] 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 13:01 UTC] 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-14 16:33 UTC] 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-14 20:47 UTC] cmb@php.net
-Status: Assigned +Status: Open -Assigned To: cmb +Assigned To:
 [2018-05-14 20:47 UTC] cmb@php.net
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.
 [2018-08-31 09:11 UTC] php-bugs-2018 at ryandesign dot com
fred5, if "[custom directory]/bin/freetype-config --cflags" returns "-I/usr/include/freetype2", as you say, then it sounds like your complaint is with freetype-config, not php. It shouldn't be doing that (and doesn't on my system). Maybe your freetype-config was built wrong, or I've just realized that freetype-config from freetype 2.8 and later uses a different codepath depending on whether or not pkg-config was found at build time and is still available at runtime. Check your freetype-config, and if it is using pkg-config, try it without; or if it isn't, try it with.
 [2018-09-07 09:47 UTC] somewheremylove dot nh87 at gmail dot com
Hi, I'm using custom path also has the problem but remove pkg-config made the error no longer shows up. Sound like a problem with freetype-config from freetype
 [2020-03-21 16:15 UTC] cmb@php.net
Well, not quite sure what to do here wrt. PHP 7.3.  As of PHP
7.4.0, pkg-config is used instead of freetype-config, so that
issue should be resolved anyway.
 [2021-05-22 13:12 UTC] krakjoe@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: krakjoe
 [2021-05-22 13:12 UTC] krakjoe@php.net
Since we've switched to pkg-config, this problem should have resolved itself in the latest versions of PHP.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Nov 21 21:01:28 2024 UTC