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
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
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: Sat Dec 07 11:01:27 2024 UTC