Php: Installing gd on buster results in freetype-config not found

[StefanPrintezis]

Not using cached versions.
I've tested the install on another device, same output.

Dockerfile:

FROM php:7.3.7-fpm
RUN apt-get update
RUN apt-get install -y --no-install-recommends \
        libfreetype6-dev \
        libjpeg62-turbo-dev \
        libpng-dev \
    && docker-php-ext-install -j$(nproc) iconv \
    && docker-php-ext-configure gd --with-freetype-dir=/usr/include/freetype --with-jpeg-dir=/usr/include/ \
    && docker-php-ext-install -j$(nproc) gd \
    && rm -r /var/lib/apt/lists/*

configure: error: freetype-config not found.
ERROR: Service 'php' failed to build: The command '/bin/sh -c apt update && apt install -y --no-install-recommends         libfreetype6-dev         libjpeg62-turbo-dev         libpng-dev     && docker-php-ext-install -j$(nproc) iconv     && docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/     && docker-php-ext-install -j$(nproc) gd     && rm -r /var/lib/apt/lists/*' returned a non-zero code: 1

The issue is present when using the latest version 7.3.7-fpm (buster)
The build succeeds when using 7.3.6-fpm (stretch)

TLDR solution for now
Use a tag with stretch instead of buster.

[StefanPrintezis]

This might be related switching to buster from stretch?

[jeyk]

This might be related switching to buster from stretch?

Probably. The changelog for libfreetype6-dev states:

• The `freetype-config' script is no longer installed by default
  (Closes: #871470, #886461). All packages depending on libfreetype6-dev
  should use pkg-config to find the relevant CFLAGS and libraries.

I guess that docker-php-ext-configure gd didn't anticipate this change...

[StefanPrintezis]

So somewhere this should be added?:

pkg-config freetype2 --libs
pkg-config freetype2 --cflags

Not sure where yet.

[marcingajda]

For people looking here for a QUICK FIX

Set the version of used image to _stretch_.

If you use for example PHP-FPM 7.3 then in your Dockerfile replace this:

FROM php:7.3-fpm

with this:

FROM php:7.3-fpm-stretch

Works for me and the error is gone.

[rjocoleman]

This shouldn't be an issue with PHP 7.4 because of the migration to pkg-config. https://github.com/php/php-src/blob/PHP-7.4/UPGRADING#L606

This has been a problem for a wee while for linux distros like Arch that have newer versions running.
https://bugs.php.net/bug.php?id=76324

The patch here adds dection via pkg-config https://git.archlinux.org/svntogit/packages.git/tree/trunk/freetype.patch?h=packages/php
(pkg-config freetype2 --cflags and pkg-config freetype2 --libs as @StefanPrintezis notes)

Extracting the PHP source early in your Dockerfile and patching it is one way to work around this.

FROM php:7.3.7-fpm

RUN apt-get update; \
  apt-get install -y --no-install-recommends \
  libfreetype6-dev \
  libjpeg62-turbo-dev \
  libpng-dev \
  pkg-config \
  patch;

ADD https://git.archlinux.org/svntogit/packages.git/plain/trunk/freetype.patch?h=packages/php /tmp/freetype.patch
RUN docker-php-source extract; \
  cd /usr/src/php; \
  patch -p1 -i /tmp/freetype.patch; \
  rm /tmp/freetype.patch

RUN docker-php-ext-configure gd --with-gd --with-freetype-dir 

I added patch and pkg-config in the example for clarity, I didn't check to see if they're included in the buster image by default.

[andreasschroth]

Kind of OT, but is it really such a good idea to switch OS version within a minor release? Didn't expect a switch from Stretch to Buster from 7.3.6 to 7.3.7. Pretty unexpected.

[barnabas-szekeres]

The issue also exist in php:7.2-apache image :(

[tvanro]

Same issue with wordpress:5.2.2-apache (that's building FROM php:7.3-apache)

FROM wordpress:5.2.2-apache
RUN apt-get update && apt-get install -y \
        libfreetype6-dev \
        libjpeg62-turbo-dev \
        libpng-dev \
    && docker-php-ext-install -j$(nproc) iconv \
    && docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/ \
    && docker-php-ext-install -j$(nproc) gd

configure: error: freetype-config not found.
ERROR: Service 'wordpress_apache' failed to build: The command '/bin/sh -c apt-get update && apt-get install -y         libfreetype6-dev        libjpeg62-turbo-dev         libpng-dev  && docker-php-ext-install -j$(nproc) iconv  && docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/  && docker-php-ext-install -j$(nproc) gd' returned a non-zero code: 1

[euphoriatek]

Same issue on php:7.2-fpm image

image: php:7.2-fpm

this line is failing: - docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/

it started happening recently.

[jxlwqq]

Temporary use:

FROM php:7.2.19-apache

or:

FROM php:7.3.6-apache

[andreasschroth]

Temporary use:

FROM php:7.2.19-apache

or:

FROM php:7.3.6-apache

No, not really a good idea. You'll end up stuck with 7.2.19 or 7.3.6 and won't receive any security fixes, etc. anymore.

Better use this:

FROM php 7.2-apache-stretch

or:

FROM php 7.3-apache-stretch

[andreasschroth]

Same issue on php:7.2-fpm image

image: php:7.2-fpm

this line is failing: - docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/

it started happening recently.

Use a base image based on Debian Stretch instead of Buster:

FROM php 7.2-fpm-stretch

[euphoriatek]

Temporary use:

FROM php:7.2.19-apache

or:

FROM php:7.3.6-apache

tried using both and also php:7.2-fpm-stretch

still the same error

checking for FreeType 2... /usr/include/
checking whether to enable JIS-mapped Japanese font support in GD... no
If configure fails try --with-webp-dir=

configure: error: jpeglib.h not found.

[andreasschroth]

I believe most people here don't really understand what's happening / going on.

The latest released docker images with the default tags (e.g. php:7.3-fpm) are now based on Debian Buster instead of Debian Stretch before.

Debian Buster uses a more up-to-date version of the libfreetype6-dev (libfreetype6) package (version 2.9.1-3 instead of 2.6.3-3.2 before). But Version 2.9.1-3 isn't shipped with freetype-config anymore, as it was removed and the package maintainers recommend to replace calls to freetype-config by calls to pkg-config.

So as I have already commented a few times before here: Switch to the tags suffixing with -stretch. E.g. instead of using php:7.3-fpm you use php:7.3-fpm-stretch. Or instead of php:7.2-apache you use php:7.2-apache-stretch. That's it.

[jvanoosterom]

same issue with php:7.1-apache

edit:
solved with changing to version: php:7.1-apache-stretch

[euphoriatek]

I believe most people here don't really understand what's happening / going on.

The latest released docker images with the default tags (e.g. php:7.3-fpm) are now based on Debian Buster instead of Debian Stretch before.

Debian Buster uses a more up-to-date version of the libfreetype6-dev (libfreetype6) package (version 2.9.1-3 instead of 2.6.3-3.2 before). But Version 2.9.1-3 isn't shipped with freetype-config anymore, as it was removed and the package maintainers recommend to replace calls to freetype-config by calls to pkg-config.

So as I have already commented a few times before here: Switch to the tags suffixing with -stretch. E.g. instead of using php:7.3-fpm you use php:7.3-fpm-stretch. Or instead of php:7.2-apache you use php:7.2-apache-stretch. That's it.

for those using 7.2-fpm image using 7.2-fpm-stretch not worked but instead 7.2.20-fpm-stretch worked

[goetas]

same issue with php:7.1-fpm, solved with changing version to php:7.1-fpm-stretch (as @jvanoosterom did)

[juuuuuu]

Same here, php:7.1-apache-stretch FTW!

[moqmar]

The same issue was closed a year ago in #608 for not being reproducable.

Relevant issue in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870618

[goetas]

This can be reproduced running just

docker run --rm php:7.1.30 bash -c 'apt-get update -qq && apt-get install libfreetype6-dev -y -qq && docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/'

[tianon]

This is a known issue in PHP upstream: https://bugs.php.net/bug.php?id=76324

For PHP 7.4+ (still a pre-release), the solution is to simply use --with-freetype and it will use pkg-config as appropriate to find freetype.

For older PHP releases, the solution is more complicated and likely involves some variation of https://git.archlinux.org/svntogit/packages.git/tree/php/trunk/freetype.patch, which IMO should really be applied as a backport upstream for handling pkg-config as a fallback in conjunction with freetype-config. We might need to consider applying something like that to our builds, but that's a solution of last resort -- we provide a stock PHP upstream experience as much as possible, and applying patches that ought to be applied upstream is something we try to strongly avoid.

For many users, the solution is likely going to be switching to explicitly use -stretch as described above. To be clear, this is exactly what those Debian release named aliases were added for, and why the stretch variants are not deprecated/removed yet.

[gries]

I'm curious on why the switch to buster was done "silently" by that I mean why isn't strech still the default and -buster an option? it just confused me as php at least since 7.* times is all about bc compatibility and this somewhat goes against that philosophy.

[wglambert]

Stretch isn't the default because Buster is now the "stable" version of Debian which is considered the "official release"
https://wiki.debian.org/DebianStability

There isn't a particularly great way of notifying users of changes outside of them checking the commits or pull requests

Using explicit tags would help to prevent breakage from an update since php-7.3-fpm-stretch will resolve to the same base OS even when the default tag changes to a different one, specifying the OS variant is along the same lines as specifying version numbers. Just as you might not want to use the tag php:7.3-fpm-alpine as you'll be updated to any major OS changes, but instead php:7.3-fpm-alpine3.10 which will just provide minor updates to 3.10.

Going a step further if a breakage is of particular concern then using the image's sha256 digest will lock you to that specific version in time, so that you could then test updates for utmost compatibility.

For a full list of tags see https://github.com/docker-library/docs/blob/master/php/README.md#supported-tags-and-respective-dockerfile-links

[regiszanandrea]

same issue with php:7.2-fpm, solved with changing version to php:7.2-fpm-stretch (as @jvanoosterom and @goetas did)

[gries]

Thanks for the clarification of the debian part :)

[DuckThom]

For now I am using the following workaround in my custom image as I'm running Magento 2.3.2 and that requires a libsodium version that's not shipped in stretch.

FROM php:7.2-apache

# Add the stretch repo so the old freetype6 versions are available
RUN echo "deb http://deb.debian.org/debian stretch main" >> /etc/apt/sources.list

# Force apt to install the old freetype6 version
RUN apt-get update && apt-get install -y --no-install-recommends \
    libfreetype6-dev=2.6.3-3.2 libfreetype6=2.6.3-3.2

RUN docker-php-ext-configure gd --with-freetype-dir=/usr/lib/x86_64-linux-gnu/

[cnlyzy]

FROM php:fpm

also have this probrem, change to

FROM php:fpm-stretch

It Works for me and the error is gone.

[MichaelBrenden]

# I just hit this bug while installing php-7.3.12 onto debian 10.1

# Freetype 2.10.1 (and maybe earlier) offers a configure option to compile its much-missed freetype-config:

cd /usr/local/src/freetype-2.10.1
./configure --prefix=/usr/local/freetype-2.10.1 --enable-freetype-config

# Then tell php configure about it

cd /usr/local/src/php-7.3.12
./configure --with-freetype-dir=/usr/local/freetype-2.10.1

[perecedero]

For those still using the freetype.patch here is a working URL.
https://git.archlinux.org/svntogit/packages.git/plain/trunk/freetype.patch?h=packages/php&id=a8e8e87f405e0631b2a4552656413735ebf9457c