php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #33685 configure: error: libjpeg.(a|so) not found.
Submitted: 2005-07-13 22:10 UTC Modified: 2005-07-14 17:02 UTC
Votes:19
Avg. Score:4.1 ± 1.1
Reproduced:15 of 15 (100.0%)
Same Version:3 (20.0%)
Same OS:5 (33.3%)
From: matt at azoogleads dot com Assigned:
Status: Wont fix Package: PHP options/info functions
PHP Version: 4.4.0 OS: RHEL 4 ES/x86_64
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: matt at azoogleads dot com
New email:
PHP Version: OS:

 

 [2005-07-13 22:10 UTC] matt at azoogleads dot com 
Description:
------------
I'm having the same problem described in Bug #32369, where I'm trying to compile JPEG support into 4.4.0 on RHEL 4 ES/x86_64 and although the location of libjpeg is detected (see below), and both libjpeg.so and libjpeg.a files exist under /usr/lib64, the configure script terminates with the error "configure: error: libjpeg.(a|so) not found."  This also seem to occur with PHP 4.3.11.

<configure snip>
checking for GD support... yes
checking for the location of libjpeg... yes
checking for the location of libpng... no
checking for the location of libXpm... no
checking for FreeType 1.x support... no
checking for FreeType 2... yes
checking for T1lib support... no
checking whether to enable truetype string function in GD... no
checking whether to enable JIS-mapped Japanese font support in GD... no
checking for fabsf... yes
checking for floorf... yes
configure: error: libjpeg.(a|so) not found.
</configure snip>

Specifying "--with-jpeg-dir=/usr" or "--with-jpeg-dir=/usr/lib64" doesn't fix the problem.

Reproduce code:
---------------
./configure
     --with-mysql=/usr \
     --with-apxs2=/usr/local/apache2/bin/apxs \
     --with-zlib \
     --with-ftp \
     --with-gd \
     --with-jpeg-dir \
     --with-freetype-dir \
     --enable-pcntl \
     --with-openssl 
     --with-curl \
     --with-dom \

Actual result:
--------------
The location of libjpeg will be detected, however the configure script will terminate with the error "configure: error: libjpeg.(a|so) not found."

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-07-13 22:45 UTC] sniper@php.net 
Check the config.log for the real reason why the check failed.
Configure outputs 'checking for the location of libjpeg... yes' because you have '--with-jpeg-dir', not that it found it.
 [2005-07-13 23:08 UTC] matt at azoogleads dot com 
I wasn't able to make out anything obvious in the config.log file (searching for any reference to 'jpeg').  Here's a copy of config.log for your reference:

http://ca.geocities.com/msiemens@rogers.com/config.log
 [2005-07-14 01:18 UTC] sniper@php.net 
I didn't notice the x86_64 there. This bug is fixed in PHP 5.1 (current CVS HEAD). It will not be fixed in PHP 4.

Workaround: 

# ln -s /usr/include /opt/include
# ln -s /usr/lib64 /opt/lib

And use these options and values for them:
--with-mysql=/opt
--with-jpeg-dir=/opt
--with-png-dir=/opt
 [2005-07-14 16:06 UTC] matt at azoogleads dot com 
I created the symlinks you mentioned which got around the libjpeg issue (thanks!), only to run into the error "configure: error: freetype2 not found!"  

I've tried using --with-freetype-dir=/opt, --with-freetype-dir=/usr and --with-freetype-dir without any luck.  Am I going to run into trouble if I run PHP 4.4.0 under 64-bit Linux?
 [2005-07-14 17:02 UTC] matt at azoogleads dot com 
Please disregard my last post, all is fine.  I didn't have the freetype-devel package installed ;-)
 [2010-04-12 07:22 UTC] aneeshknlr at gmail dot com 
Easy Workaround..


# ln -s /usr/lib64/libjpeg.so /usr/lib/
# ln -s /usr/lib64/libpng.so /usr/lib/
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Tue Nov 26 06:01:31 2024 UTC