New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ext/gd/config.m4: don't forget GDLIB_CFLAGS in feature tests #13724
Conversation
Thanks for fixing this one so quick @orlitzky 🎉 This seems to be working fine, yes. Even when doing customization like this:
We'll add it to PHP-8.2 branch, since this was added there also. |
(not related to this PR) Otherwise, in the future, perhaps it would be better to go with a bit different approach in these cases. Because that GD_SHARED_LIBADD is populated when building ext/gd as shared and INCLUDES might include things that are important for the check (for example includes from a separate libavif). I'll see if I can add the PHP_PUSH and PHP_POP macros that manage all these CPPFLAGS, CFLAGS, LIBS, LDFLAGS and INCLUDES like this. And it might be simpler and less error prone to only do this and be confident that flags are saved and restored properly: PHP_PUSH() dnl store CFLAGS, LIBS, LDFLAGS, INCLUDES
dnl ... change CFLAGS, LIBS, LDFLAGS, INCLUDES as needed for the next checks
dnl ... autoconf checks with changed flags
PHP_POP() dnl Restore CFLAGS, LIBS, LDFLAGS, INCLUDES |
In commit 85e5635, a feature test for the various libgd image formats was added. That test however erroneously omits the GDLIB_CFLAGS (from pkg-config) during compilation. This can lead to build failures and therefore false negatives from the test. Here, we add $GDLIB_CFLAGS to $CFLAGS for the duration of the test. Closes phpGH-12019
3c78f15
to
3a63538
Compare
I force-pushed a fix to overwrite my misleading commit message. I noticed #13727 during testing but it's unrelated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works great. Thanks @orlitzky
This does not change behaviour of the tests at all: configure:37620: checking for working gdImageCreateFromWebp in libgd There is still missing the include path. Maybe GDLIB_CFLAGS are not yet accessible when running the tests? |
@rs-bc have you recreated configure script? I've checked this on FreeBSD and this seemed to have found it: ./configure --enable-gd --with-external-gd The GDLIB_CFLAGS was populated properly but I can recheck what's happening. |
What do you mean be "recreated configure script"? |
To recreate configure script this needs to be run git checkout PHP-8.2
wget https://github.com/php/php-src/pull/13724.patch
git apply
./buildconf
./configure --enable-gd --with-external-gd
...
checking whether to enable JIS-mapped Japanese font support in GD... no
checking for gdlib >= 2.1.0... yes
checking for working gdImageCreateFromPng in libgd... yes
checking for working gdImageCreateFromAvif in libgd... no
checking for working gdImageCreateFromWebp in libgd... yes
checking for working gdImageCreateFromJpeg in libgd... yes
checking for working gdImageCreateFromXpm in libgd... no
checking for working gdImageCreateFromBmp in libgd... yes
checking for working gdImageCreateFromTga in libgd... yes
checking for gdFontCacheShutdown in -lgd... yes
... In config.log I see these:
|
And this isn't available in the released PHP-8.2 archive downloadable file, yet. PHP release needs to be done on the next schedule - 8.2.18 in about a week or so. |
Ah, that did the trick. Thank you very much. |
Yes, sorry, |
Applied via 0079932 to PHP-8.2 and up. |
In commit 85e5635, a feature test for the various libgd image formats was added. That test however erroneously omits the
GDLIB_CFLAGS
(from pkg-config) during compilation. This can lead to build failures and therefore false negatives from the test.Here, we add
$GDLIB_CFLAGS
to$CFLAGS
for the duration of the test.Moreover, we replace
$GD_SHARED_LIBADD
with$GDLIB_LIBS
in the same test. The variable$GD_SHARED_LIBADD
is actually empty when we try to use it. Fortunately(?), the library flags are appended elsewhere, so this was not causing a problem. But of course it's better to explicitly do the right thing.Closes GH-12019