Are you using the bundled libgd, or an external one?

I described it in "Description:" :-)

Here's a proposed fix:

--- ext/gd/gd.c 2009-01-31 16:27:52.000000000 +0100          
+++ ext/gd/gd.c.oden    2009-03-27 20:27:14.000000000 +0100  
@@ -55,6 +55,15 @@                                           
                                                             
 #if HAVE_LIBGD                                              
                                                             
+#ifdef HAVE_GD_PNG                                          
+/* needs to be first */                                     
+# include <png.h>                                           
+#endif
+
+#ifdef HAVE_GD_JPG
+# include <jpeglib.h>
+#endif
+
 static int le_gd, le_gd_font;
 #if HAVE_LIBT1
 #include <t1lib.h>
@@ -1293,8 +1302,13 @@ PHP_MINFO_FUNCTION(gd)
 #endif
 #ifdef HAVE_GD_JPG
        {
+#if HAVE_GD_BUNDLED
                char tmp[12];
                snprintf(tmp, sizeof(tmp), "%d", gdJpegGetVersionInt());
+#else
+               char tmp[256];
+               snprintf(tmp, sizeof(tmp), "%d", JPEG_LIB_VERSION);
+#endif
                php_info_print_table_row(2, "JPG Support", "enabled");
                php_info_print_table_row(2, "libJPEG Version", tmp);
        }
@@ -1302,7 +1316,11 @@ PHP_MINFO_FUNCTION(gd)

 #ifdef HAVE_GD_PNG
        php_info_print_table_row(2, "PNG Support", "enabled");
+#if HAVE_GD_BUNDLED
        php_info_print_table_row(2, "libPNG Version", gdPngGetVersionString());
+#else
+       php_info_print_table_row(2, "libPNG Version", PNG_LIBPNG_VER_STRING);
+#endif
 #endif
 #ifdef HAVE_GD_WBMP
        php_info_print_table_row(2, "WBMP Support", "enabled");

You should really not use the system libgd, especially not on the following systems:
- debian
- RHEL
- Centos

The problem still has to be fixed tho' :)

The PHP devs should try harder to not bundle common libraries and instead push private changes upstream (IMHO).

That argument completely falls apart if you do a bit of research on who the upstream for the gd library is.

You missed my point.

These distributions do not have updated libraries, or even worst for debian, they break the compatibility with the normal GD.

I'm working to sync the external gd and php's gd so both can be used smoothly, but I have serious doubts that Debian will change, for example.

Upstream gd is nowadays libgd.org and I read there "The library was originally developped by Thomas Boutell and is now maintained by Pierre-A. Joye under the umbrella of PHP.net.". Is this a problem?

Right, so you figured it out.  You are talking to Pierre here.  He is the upstream maintainer of the library.  And the library is a PHP project.  Telling us to do a better job pushing changes upstream (to ourselves?) doesn't make much sense.

Pierre: is there any summary on what has to be done exactly to sync both libraries so distributions can just ship one copy of libgd ?

Maybe all interested parties can hack into it.

Excuse me for bothering you with petty issues.

Why is it the bundled libgd is not in sync with the more "official" libgd as you are the sole upstream maintainer? gd hasn't had a new release since 2007-11-28, and none of the bling-bling found in the bundled libgd has found its way into any official libgd release.

There are other bundled libraries. What about them then and private changes?

There is work being done in libgd.org to bring 2.1.0 out (which should be synced with php). All fixes are done in both libraries (thanks Tabe for taking care of most of them) and many features have made their way. By the way, if the tempo is too slow, you can always give us a hand.

I'm not willing to begin again a discussion with the Debian maintainer, I tried many times without success.

Thanks Pierre,

What about the private changes in libzip? Will you be able to sync that with upstream as well?

Please do not use this report to discuss other topics.

But to answer your questions, yes, they are provided as patch upstream as well and we try to keep everything synced as much as possible.

But they tend to stay behind for some fixes, especially edge cases for crashes or windows support. You can follow the libzip mailing list if you are interested.

Thanks Pierre,

I'm looking forward to a gd with all the bling-bling that's in the bundled gd in php, as well as with libzip.

The private changes in the bundled libmagic library (file-5.x) is also quite annoying.

"The private changes in the bundled libmagic library (file-5.x) is also
quite annoying."

It will end like mod_mime, to only use the DB. 

For your information, the gdJpegGetVersionInt error is fixed in CVS, I keep this bug open as it reflects what I'm working on: allows to use either the bundled library or a decent external version without loosing features.

Seems OK with 5.3.0RC2 that now also is in Mandriva Cooker. Thanks Pierre.

5.3 specific todos are fixed, making this bug not version specific now.

Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at 
http://www.php.net/downloads.php

Fixed, ext/gd can be built against external GD while having the new features from the bundled version exposed as well. The other part of the job is not PHP related (sync libs).