Concerns about syncing bundled libgd to upstream 2.4 (GH-22532)

Ciao Giovanni,

Il 08/07/2026 12:01, Giovanni Giacobbi ha scritto:

 1) This code was introduced in the upstream repository less than a
month ago, so it is relatively "young"

Likewise, some of the code that will end up in 8.6 is "young" too.

 2) libgd-2.4.0 was never released nor tagged, thus no major distros
are shipping it

Perhaps there are also plans to release libgd 2.4 soon enough?

 3) PHP-8.6 already tagged alpha1, giving overall a short timespan to
test the new bundled library

We're currently ~5 weeks away from feature freeze, so there's still time
for 8.6.

 4) Introducing features in ext/gd that exist only in libgd-2.4 would
in fact force the bundled library as the only build option
The PR doesn't remove support for older non-bundled libgd versions: the
new functionality won't be available, as it happens with all extensions
supporting multiple versions of external libraries.

Cheers

Matteo Beccati

On Wed, Jul 8, 2026 at 12:04 PM Giovanni Giacobbi giovanni@giacobbi.net
wrote:

Greetings,

For many years, PHP shipped with a bundled libgd as an alternative to the
system version. The bundled libgd is a custom version of upstream,
originally based on GD-2.0, and over time cherry-picked backports and
customizations, such as custom memory allocators, have been made. Due to
this divergence, it is difficult to assess exactly what the changes are in
the bundled library compared to upstream, as diffing against any upstream
branch or tag yields a massive diff with a lot of noise.

A proper resync with upstream has been due for a long time, and very
needed, and I think it's great that this is happening, but I have some
concerns I would like to highlight, just to be on the safe side of things.

In the past few years, upstream libgd repository has seen very low
activity, but recently development was restarted at a very fast pace, with
a lot of new interesting features being added to master and several fixes
to the stable branch.

Last week GH-22532 [1] was opened for php-src to "Sync bundled libgd to
2.4.0".

Here is a quick recap on the upstream repository [2] at the time of
writing:

libgd/GD-2.3:

• Last release 2.3.3, september 2011
• Activity until may 2026 (src/ only): 38 commits, 21 files changed, 179
  insertions(+), 102 deletions(-)
• Activity since may 2026 (src/ only): 21 commits, 21 files changed,
  1.234 insertions(+), 386 deletions(-)

libgd/master (GD-2.4):

• Never released
• Activity since may 2026 (src/ only): 68 commits, 136 files changed,
  67.954 insertions(+), 47.472 deletions(-)

This is the statistics on the PR in php-src at the time of writing:
$ git diff --stat upstream/master...gh/22532 | tail -1
137 files changed, 142.451 insertions(+), 32.476 deletions(-)

Moreover, this is what i obtain by diffing the tip of the PR with the
current libgd/master:
$ diff -ur libgd-src/src php-src/ext/gd/libgd | diffstat | tail -1
84 files changed, 93.108 insertions(+), 15.278 deletions(-)

I am NOT questioning the quality of the work, the new features in the
library look very promising and they would be a great addition to PHP, but
I have the following concerns I wanted to share:

1. This code was introduced in the upstream repository less than a month
   ago, so it is relatively "young"
2. libgd-2.4.0 was never released nor tagged, thus no major distros are
   shipping it
3. PHP-8.6 already tagged alpha1, giving overall a short timespan to test
   the new bundled library
4. Introducing features in ext/gd that exist only in libgd-2.4 would in
   fact force the bundled library as the only build option

Given the above, I'd like to hear people's opinions on the matter. My
concern is that hitting the PHP-8.6 timeline may end up forcing rushed
decisions, and it would be preferable to wait for libgd-2.4.0 to have an
actual upstream release, and to give time to a broader audience to test the
new features before we commit to shipping them.

I don't see this as a problem. The update was long due and if we go early
for 2.4, then both versions could stabilise in the same time. I think that
syncing releases would be really great, then we could more easily follow
2.4 with fixes. Volker has also done a deep AI review which found some
issues. Once all of those get addressed, it should be good enough for
master merge IMHO. This should ideally happen before beta1 so it really
depends if it's ready in time for that.

Kind regards,

Jakub

Greetings,

For many years, PHP shipped with a bundled libgd as an alternative to the system version. The bundled libgd is a custom version of upstream, originally based on GD-2.0, and over time cherry-picked backports and customizations, such as custom memory allocators, have been made. Due to this divergence, it is difficult to assess exactly what the changes are in the bundled library compared to upstream, as diffing against any upstream branch or tag yields a massive diff with a lot of noise.

A proper resync with upstream has been due for a long time, and very needed, and I think it's great that this is happening, but I have some concerns I would like to highlight, just to be on the safe side of things.

In the past few years, upstream libgd repository has seen very low activity, but recently development was restarted at a very fast pace, with a lot of new interesting features being added to master and several fixes to the stable branch.

Last week GH-22532 [1] was opened for php-src to "Sync bundled libgd to 2.4.0".

Here is a quick recap on the upstream repository [2] at the time of writing:

libgd/GD-2.3:

• Last release 2.3.3, september 2011
• Activity until may 2026 (src/ only): 38 commits, 21 files changed, 179 insertions(+), 102 deletions(-)
• Activity since may 2026 (src/ only): 21 commits, 21 files changed, 1.234 insertions(+), 386 deletions(-)

libgd/master (GD-2.4):

• Never released
• Activity since may 2026 (src/ only): 68 commits, 136 files changed, 67.954 insertions(+), 47.472 deletions(-)

This is the statistics on the PR in php-src at the time of writing:
$ git diff --stat upstream/master...gh/22532 | tail -1
137 files changed, 142.451 insertions(+), 32.476 deletions(-)

Moreover, this is what i obtain by diffing the tip of the PR with the current libgd/master:
$ diff -ur libgd-src/src php-src/ext/gd/libgd | diffstat | tail -1
84 files changed, 93.108 insertions(+), 15.278 deletions(-)

I am NOT questioning the quality of the work, the new features in the library look very promising and they would be a great addition to PHP, but I have the following concerns I wanted to share:

1. This code was introduced in the upstream repository less than a month ago, so it is relatively "young"
2. libgd-2.4.0 was never released nor tagged, thus no major distros are shipping it
3. PHP-8.6 already tagged alpha1, giving overall a short timespan to test the new bundled library
4. Introducing features in ext/gd that exist only in libgd-2.4 would in fact force the bundled library as the only build option

Given the above, I'd like to hear people's opinions on the matter. My concern is that hitting the PHP-8.6 timeline may end up forcing rushed decisions, and it would be preferable to wait for libgd-2.4.0 to have an actual upstream release, and to give time to a broader audience to test the new features before we commit to shipping them.

Kind regards
Giovanni Giacobbi
@thg2k

[1] https://github.com/php/php-src/pull/22532/

[2]
git log --oneline gd-2.3.3..53cb765b -- src | wc -l
git diff --stat gd-2.3.3..53cb765b -- src | tail -1

git log --oneline 53cb765b..GD-2.3 -- src | wc -l
git diff --stat 53cb765b..GD-2.3 -- src | tail -1

git log --oneline 185b1f56..master -- src | wc -l
git diff --stat 185b1f56..master -- src | tail -1

I think it's too late in PHP 8.6 to merge it now. I also don't see any
need to rush things. Just wait until libgd 2.4 is released and merge
the changes into the next PHP version.

Hi Giovanni,

Greetings,

For many years, PHP shipped with a bundled libgd as an alternative to the system version. The bundled libgd is a custom version of upstream, originally based on GD-2.0, and over time cherry-picked backports and customizations, , have been made. Due to this divergence, it is difficult to assess exactly what the changes are in the bundled library compared to upstream, as diffing against any upstream branch or tag yields a massive diff with a lot of noise.

Mainly custom memory allocators since it was done.

A proper resync with upstream has been due for a long time, and very needed, and I think it's great that this is happening, but I have some concerns I would like to highlight, just to be on the safe side of things.

Indeed.

In the past few years, upstream libgd repository has seen very low activity, but recently development was restarted at a very fast pace, with a lot of new interesting features being added to master and several fixes to the stable branch.

Last week GH-22532 [1] was opened for php-src to "Sync bundled libgd to 2.4.0".

It is purely a sync, with no BC but bug fixes in two functions which
were not working properly.
Volker ran audits and has been approved.

Here is a quick recap on the upstream repository [2] at the time of writing:

libgd/GD-2.3:

• Last release 2.3.3, september 2011
• Activity until may 2026 (src/ only): 38 commits, 21 files changed, 179 insertions(+), 102 deletions(-)
• Activity since may 2026 (src/ only): 21 commits, 21 files changed, 1.234 insertions(+), 386 deletions(-)

libgd/master (GD-2.4):

• Never released
• Activity since may 2026 (src/ only): 68 commits, 136 files changed, 67.954 insertions(+), 47.472 deletions(-)

Many additions. And that's the 2nd PR I like to propose actually
making additions to the extension itself (draft here
https://wiki.php.net/rfc/ext-gd-2.4)

Moreover, this is what i obtain by diffing the tip of the PR with the current libgd/master:
$ diff -ur libgd-src/src php-src/ext/gd/libgd | diffstat | tail -1
84 files changed, 93.108 insertions(+), 15.278 deletions(-)

I don't consider LOCs of any relevant values. However the breakdown if
you remove the new additions, which are not used by php in this PR,
they are CS (both sides), merge features that should be in both or add
what is needed so that both provide the same level of quality and
features.

I am NOT questioning the quality of the work, the new features in the library look very promising and they would be a great addition to PHP, but I have the following concerns I wanted to share:

1. This code was introduced in the upstream repository less than a month ago, so it is relatively "young"

No. It was in master at that time.

2. libgd-2.4.0 was never released nor tagged, thus no major distros are shipping it

Because I want to follow the 8.6 release so both are available at the
same time. The 1st PR being a pure sync with no actual changes in the
behavior of the PHP extension but better support for quite a few
codecs and safer (full corpus codecs conformance for 90% of the
codecs),

3. PHP-8.6 already tagged alpha1, giving overall a short timespan to test the new bundled library

I mailed RMs before alpah1 was tagged, and also along other things
(sec issue on gh not part of releases), I did not get any answer so
far. And alpha1 was always still time for additions.

4. Introducing features in ext/gd that exist only in libgd-2.4 would in fact force the bundled library as the only build option

As I mentioned in the PR and here, nothing from what exists is
affected. Also I am not sure about that point. We have hundred of
featues in php depending on libraries versions, system libs available,
or even specific functions. Having functions requiring a library
version, bundled or not, is extremely common too.

Given the above, I'd like to hear people's opinions on the matter. My concern is that hitting the PHP-8.6 timeline may end up forcing rushed decisions, and it would be preferable to wait for libgd-2.4.0 to have an actual upstream release, and to give time to a broader audience to test the new features before we commit to shipping them.

I would have appreciated you would let the PR itself go through RFC
when I pointed it out to you in mail about deprecation for 8.6 (with
or without that). That would have given a much more complete, and
positive, introduction about that specific PR and what is the one
following once it can be approved, adding actual new features to php's
ext. I am fuine with this mail but it just comes here with incomplete
information and not mentioning the reviews, audits (PHPF's Volker
security team) and full tests passing. That mail focused on LOCs
changed instead :)

Cheers,

--
Pierre

@pierrejoye