php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #47812 undefined symbol: gdJpegGetVersionInt
Submitted: 2009-03-27 19:16 UTC Modified: 2010-04-28 16:58 UTC
From: oeriksson at mandriva dot com Assigned: pajoye (profile)
Status: Closed Package: GD related
PHP Version: * OS: Mandriva Linux
Private report: No CVE-ID: None
 [2009-03-27 19:16 UTC] oeriksson at mandriva dot com
Description:
------------
I get an unresolved symbol when linking against system libgd.


Reproduce code:
---------------
Just running php-cli

Expected result:
----------------
Should work.

Actual result:
--------------
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/extensions/gd.so' - /usr/lib64/php/extensions/gd.so: undefined symbol: gdJpegGetVersionInt in Unknown on line 0

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-03-27 19:36 UTC] derick@php.net
Are you using the bundled libgd, or an external one?
 [2009-03-27 19:45 UTC] oeriksson at mandriva dot com
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");
 [2009-03-27 19:49 UTC] pajoye@php.net
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' :)
 [2009-03-27 19:59 UTC] oeriksson at mandriva dot com
The PHP devs should try harder to not bundle common libraries and instead push private changes upstream (IMHO).
 [2009-03-27 20:04 UTC] rasmus@php.net
That argument completely falls apart if you do a bit of research on who the upstream for the gd library is.
 [2009-03-27 20:05 UTC] pajoye@php.net
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.
 [2009-03-27 20:14 UTC] oeriksson at mandriva dot com
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?
 [2009-03-27 20:18 UTC] rasmus@php.net
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.
 [2009-03-27 20:33 UTC] crrodriguez at opensuse dot org
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.
 [2009-03-27 20:40 UTC] oeriksson at mandriva dot com
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?
 [2009-03-27 20:55 UTC] pajoye@php.net
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.

 [2009-03-27 21:10 UTC] oeriksson at mandriva dot com
Thanks Pierre,

What about the private changes in libzip? Will you be able to sync that with upstream as well?
 [2009-03-27 21:29 UTC] pajoye@php.net
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.
 [2009-03-30 17:38 UTC] oeriksson at mandriva dot com
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.
 [2009-03-30 17:45 UTC] pajoye@php.net
"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. 
 [2009-05-03 22:15 UTC] pajoye@php.net
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.
 [2009-05-18 10:39 UTC] oeriksson at mandriva dot com
Seems OK with 5.3.0RC2 that now also is in Mandriva Cooker. Thanks Pierre.
 [2009-06-18 15:12 UTC] pajoye@php.net
5.3 specific todos are fixed, making this bug not version specific now.
 [2010-04-28 16:58 UTC] pajoye@php.net
-Status: Assigned +Status: Closed
 [2010-04-28 16:58 UTC] pajoye@php.net
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).
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Oct 09 03:01:28 2024 UTC