Bug 152171 - imagejpeg() function is not supported
imagejpeg() function is not supported
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: php (Show other bugs)
rawhide
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-25 11:00 EST by Dawid Zamirski
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version: 5.0.3-5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-03-31 04:12:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
my gd.ini (45 bytes, text/plain)
2005-03-29 18:38 EST, Dawid Zamirski
no flags Details
my php.ini (37.55 KB, text/plain)
2005-03-29 18:39 EST, Dawid Zamirski
no flags Details
Log (163.24 KB, text/plain)
2005-03-30 09:44 EST, Dawid Zamirski
no flags Details

  None (edit)
Description Dawid Zamirski 2005-03-25 11:00:48 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

Description of problem:
A call to imagejpeg funvtion in php code returns this error message:
"Call to undefined function imagejpeg() in [...]"


Version-Release number of selected component (if applicable):
php-5.0.3-4   php-gd-5.0.3-4

How reproducible:
Always

Steps to Reproduce:
1. see above
2.
3.
  

Expected Results:  calling imagejpeg($imageResource) should output the image to the borwser window.

Additional info:

I have installed all the packages required to support jpeg files:
php-5.0.3-4
php-gd-5.0.3-4
libjpeg-6b-34

rpm -ql libjpeg.x86_64 gives:

/usr/bin/cjpeg
/usr/bin/djpeg
/usr/bin/jpegtran
/usr/bin/rdjpgcom
/usr/bin/wrjpgcom
/usr/lib64/libjpeg.so.62
/usr/lib64/libjpeg.so.62.0.0
/usr/share/doc/libjpeg-6b
/usr/share/doc/libjpeg-6b/README
/usr/share/doc/libjpeg-6b/usage.doc
/usr/share/man/man1/cjpeg.1.gz
/usr/share/man/man1/djpeg.1.gz
/usr/share/man/man1/jpegtran.1.gz
/usr/share/man/man1/rdjpgcom.1.gz
/usr/share/man/man1/wrjpgcom.1.gz


phpinfo() returns that php was compiled using --with-jpeg-dir=/usr
Comment 1 Joe Orton 2005-03-29 05:54:26 EST
Can you attach the complete phpinfo() output?
Comment 2 Dawid Zamirski 2005-03-29 09:44:42 EST
The link to my phpinfo:
http://maners.no-ip.com/phpinfo.php

Link to the page where imagejpeg() is used:
http://maners.no-ip.com/metafier/

When you click on one of the thumbnails it should display full-size image but
instead it throws an error that jpeg image contains errors and cannot be
displayed. Viewing the source code of the page with the error will reveal the
error message from php which states that imagejpeg function is uundefined. the
code that is used to display fullsize image looks likt this:

if(isset($_GET['img']))
{
        header('Content-type: image/jpeg');
        echo imagejpeg(rotateImage($images.$_GET['img']));
}

function rotateImage($jpgFile)
{
        $exif = read_exif_data($jpgFile, 0, true);
        $orientation = $exif["IFD0"]["Orientation"];
        $image = imagecreatefromjpeg($jpgFile);
        if( $orientation == 8 )
        {
                $image = imagerotate($image, 90, 0);
        }
        return $image;
}

Comment 3 Joe Orton 2005-03-29 09:49:49 EST
There is no gd section in there, have you disabled gd support?

  cat /etc/php.d/gd.ini

Comment 4 Dawid Zamirski 2005-03-29 10:01:53 EST
Whoops, my server is currently down due to gdm update crash :-(. Therefore I
cannot post my gd.ini right now. However I didn't enable/disable anything
manually - all config files come from the stock installation of FC3 that was
updgraded to FC4 Test 1. I'll bring my server  back up when I get home from work
at around 6:00pm EST and post my config files. 

Comment 5 Dawid Zamirski 2005-03-29 18:38:59 EST
Created attachment 112438 [details]
my gd.ini
Comment 6 Dawid Zamirski 2005-03-29 18:39:51 EST
Created attachment 112439 [details]
my php.ini
Comment 7 Dawid Zamirski 2005-03-29 18:40:32 EST
Ok, I'm back online, so I have attached my gd.ini from /etc/php.d/ and php.ini
from /etc. Those files look fine for me, so below are rpm queries with gd
related packages:

[maners@athlon64 ~]$ rpm -q gd
gd-2.0.33-1
gd-2.0.33-1
[maners@athlon64 ~]$ rpm -ql gd
/usr/lib/libgd.so.2
/usr/lib/libgd.so.2.0.0
/usr/share/doc/gd-2.0.33
/usr/share/doc/gd-2.0.33/COPYING
/usr/share/doc/gd-2.0.33/README-JPEG.TXT
/usr/share/doc/gd-2.0.33/entities.html
/usr/share/doc/gd-2.0.33/index.html
/usr/lib64/libgd.so.2
/usr/lib64/libgd.so.2.0.0
/usr/share/doc/gd-2.0.33
/usr/share/doc/gd-2.0.33/COPYING
/usr/share/doc/gd-2.0.33/README-JPEG.TXT
/usr/share/doc/gd-2.0.33/entities.html
/usr/share/doc/gd-2.0.33/index.html
[maners@athlon64 ~]# rpm -ql php-gd
/etc/php.d/gd.ini
/usr/lib64/php/modules/gd.so

Also the link I posted with the example of imagejpeg use should be like the
following:
http://maners.no-ip.com/metalfier/
Comment 8 Joe Orton 2005-03-30 02:36:49 EST
It still looks to me like you don't have the gd extension enabled for whatever
reason.   What's the complete output of "php -m"?
Comment 9 Dawid Zamirski 2005-03-30 07:49:44 EST
Well, it seems to be enabed at least in theory :-)

[maners@athlon64 ~]$ php -m
[PHP Modules]
bcmath
bz2
calendar
ctype
curl
dba
dbx
dio
exif
ftp
gd
gettext
gmp
iconv
libxml
mime_magic
mysql
mysqli
openssl
pcntl
pcre
posix
pspell
session
shmop
SimpleXML
sockets
SPL
standard
sysvsem
sysvshm
tokenizer
wddx
xml
yp
zlib

[Zend Modules]

Comment 10 Joe Orton 2005-03-30 07:56:08 EST
Can you show the output via Apache of a page which just has:

<?php
print_r(get_loaded_extensions());
?> 

and also attach /var/log/httpd/error_log.
Comment 11 Dawid Zamirski 2005-03-30 09:44:12 EST
Created attachment 112454 [details]
Log
Comment 12 Dawid Zamirski 2005-03-30 09:46:26 EST
GD is not here:
http://maners.no-ip.com/extensions.php
Comment 13 Dawid Zamirski 2005-03-30 10:07:08 EST
Ok, the problem is solved. I looked into the error_log file and it came out that
my php.ini in /etc had extension_dir=/usr/lib/php4 instead of
extension_dir=/usr/lib64/php/modules

Thank you for your help.
Comment 14 Joe Orton 2005-03-31 04:12:30 EST
Yup, well spotted.  I've changed the package so that on this upgrade, the old
php.ini will be replaced by the new, correct php.ini by default.

Note You need to log in before you can comment on or make changes to this bug.