# Suggested libgd ABI change leading to ext/gd BC break - Thread: https://externals.io/message/103743 - Original archive: https://news-web.php.net/php.internals/103743 - Started by Christoph M. Becker on 2019-01-15T11:13:43+00:00 - Messages: 4 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #103743 — Christoph M. Becker — 2019-01-15T11:13:43+00:00 URL: https://externals.io/message/103743#103743 Hi! Most recently, a pull request has been submitted for libgd[1], which suggests to define image IO functions for several image formats unconditionally; if the format is not supported, the IO functions would fail with an error notice. This would break the current ext/gd configuration, since it relies on checks for the existence of these functions[2] to define the respective PHP functions conditionally and for introspection (e.g. gd_info()). In other words, building ext/gd against the PR would define imagecreatefromweb() even if WebP is not supported. This would break code relying on `if (function_exists('imagecreatefromweb'))` or such. We would have to change ext/gd/config.m4 accordingly to keep BC (we could either rely on gdSupportsFileType() or actually call the functions checking for the error message during build-time). However, I wonder about stable PHP versions, and particularly PHP 7.1 which is supposed to receive only security updates. If the libgd PR will be merged and released with libgd 2.3.0 which may well happen during this year, unmodified PHP versions would break BC if built against libgd 2.3.0. Suggestions how to deal with this are welcome! [1] [2] -- Christoph M. Becker --- ## #103745 — Zeev Suraski — 2019-01-15T12:32:13+00:00 URL: https://externals.io/message/103743#103745 · In reply to: #103743 > > > Hi! > > Most recently, a pull request has been submitted for libgd[1], which > suggests to define image IO functions for several image formats > unconditionally; if the format is not supported, the IO functions would > fail with an error notice. This would break the current ext/gd > configuration, since it relies on checks for the existence of these > functions[2] to define the respective PHP functions conditionally and > for introspection (e.g. gd_info()). In other words, building ext/gd > against the PR would define imagecreatefromweb() even if WebP is not > supported. This would break code relying on `if > (function_exists('imagecreatefromweb'))` or such. Given this downside, what is the upside of introducing this change? Zeev --- ## #103747 — Christoph M. Becker — 2019-01-15T13:29:31+00:00 URL: https://externals.io/message/103743#103747 · In reply to: #103745 > > […] > > Given this downside, what is the upside of introducing this change? Basically, to be able to switch libgd.so without recompiling its clients, see . Of course, that wouldn't work for ext/gd as it is now, but that is a different story. We have to deal with whatever the libgd developers decide. -- Christoph M. Becker --- ## #103748 — Zeev Suraski — 2019-01-15T13:38:36+00:00 URL: https://externals.io/message/103743#103748 Sent from my mobile Most recently, a pull request has been submitted for libgd[1], which suggests to define image IO functions for several image formats unconditionally; if the format is not supported, the IO functions would fail with an error notice. This would break the current ext/gd configuration, since it relies on checks for the existence of these functions[2] to define the respective PHP functions conditionally and for introspection (e.g. gd_info()). In other words, building ext/gd against the PR would define imagecreatefromweb() even if WebP is not supported. This would break code relying on `if (function_exists('imagecreatefromweb'))` or such. Given this downside, what is the upside of introducing this change? Basically, to be able to switch libgd.so without recompiling its clients, see . Of course, that wouldn't work for ext/gd as it is now, but that is a different story. We have to deal with whatever the libgd developers decide. If that's the reason - I believe it should be possible to retain the current behavior and also get the benefit of being able to replace the underlying library. I think we can just register the relevant functions dynamically in MINIT based on what's available in runtime. I've seen the pattern of using `function_exists()` to determine whether or not a given format is supported in numerous places over the years, so I think we should avoid breaking it. Zeev