ID: 50125
User updated by: vhaban at atlas dot cz
Reported By: vhaban at atlas dot cz
Status: Bogus
Bug Type: GD related
Operating System: Fedora 11 x86 64bit
PHP Version: 5.3.1RC3
New Comment:
I have found the cause of libjpeg version mixture, but the problem with
unability to open jpeg images remains.
The symbolic link /usr/lib64/libjpeg.so was set to 6.2 version file, I
had to do:
rm /usr/lib64/libjpeg.so
ln -s /usr/share/jpeg-7/lib/libjpeg.so.7.0.0 /usr/lib64/libjpeg.so
Now there is no error message in /etc/httpd/logs/error_log, but I still
cannot open the jpeg files with the same result as described above.
Previous Comments:
------------------------------------------------------------------------
[2009-11-17 18:39:48] vhaban at atlas dot cz
So, I have found the possible cause of all this. In
httpd/logs/error_log I have got this message:
Wrong JPEG library version: library is 62, caller expects 70
The library seems to be badly configured somewhere. I will report more
when I find the cause.
------------------------------------------------------------------------
[2009-11-16 20:37:06] vhaban at atlas dot cz
After PHP compilation I also run:
libtool --finish /root/install/www/php/php-5.3.1RC3/libs
I also do the restart of Apache:
/etc/httpd/bin/apachectl restart
The above mentioned configuration might be wrong in
--with-jpeg-dir=/usr/share/jpeg-7/lib, but I have tried it also without
the lib at the end and the result seems to be the same.
Thanks.
------------------------------------------------------------------------
[2009-11-16 20:19:40] vhaban at atlas dot cz
I am running also PHP 5.3.0 on an old Fedora Core 6 x86_64 machine with
an AMD64 processor and it is working well even with the return type bug.
But the machine with Fedora 11 is a Core 2 Duo notebook.
Firstly, I compile jpeg-7:
./configure --prefix=/usr/share/jpeg-7
make
make install
Secondly, I compile PHP with internal GD:
./configure --with-apxs2=/etc/httpd/bin/apxs --with-libdir=lib64
--with-gd --with-jpeg-dir=/usr/share/jpeg-7/lib --with-png-dir
--with-xsl
make
make install
phpinfo() tells about the gd this:
gd
GD Support enabled
GD Version bundled (2.0.34 compatible)
GIF Read Support enabled
GIF Create Support enabled
JPEG Support enabled
libJPEG Version unknown
PNG Support enabled
libPNG Version 1.2.37
WBMP Support enabled
XBM Support enabled
Directive Local Value Master Value
gd.jpeg_ignore_warning 1 0
The code source is:
<?php
ini_set("memory_limit","384M");
ini_set("gd.jpeg_ignore_warning",1);
$img = imagecreatefromjpeg("img/gdtest.jpg");
phpinfo();
?>
The image is an empty jpeg file created with GIMP.
GIMP Image properties tells:
640 × 400 pixels, RGB color, JPEG image, etc.
What I get when I run the script is:
Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]: gd-jpeg:
JPEG library reports unrecoverable error: in /.../phpinfo.php on line 4
Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]:
'img/gdtest.jpg' is not a valid JPEG file in /.../phpinfo.php on line 4
Where ... is the full path to the script.
I can also send the jpeg image, but I think that the problem is
somewhere else.
Thank you for any further help.
------------------------------------------------------------------------
[2009-11-10 12:24:43] [email protected]
jpeg7 only format is not supported when the jpeg6 library is used.
I think you are just mixing formats, all latest php releases work just
fine with all jpeg I have here.
Btw, you should not use the external GD, I recomment to use the bundled
version only.
no bug > bogus. Unless you can clearly reproduce it and provide us a
file as well.
------------------------------------------------------------------------
[2009-11-10 12:18:17] vhaban at atlas dot cz
I have compiled GD with libjpeg 6.2 and 7 and both behave the same.
However, phpinfo reports the version of libjpeg as unknown. Is this
correct? When I use internal GD, then it reports 2.0.34. When I use
external compiled GD, then there is just 2.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/50125
--
Edit this bug report at http://bugs.php.net/?id=50125&edit=1
