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

go to bug id or search bugs for

Bug #34722 configure is confused by 64bit x86_64 on Fedora
Submitted: 2005-10-03 23:09 UTC Modified: 2005-10-04 18:00 UTC
Votes:10
Avg. Score:4.3 ± 0.8
Reproduced:9 of 10 (90.0%)
Same Version:2 (22.2%)
Same OS:4 (44.4%)
From: voidvoidpointer at yahoo dot com Assigned:
Status: Wont fix Package: GD related
PHP Version: 5.0.5 OS: Fedora Core 2 x86_64
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: voidvoidpointer at yahoo dot com
New email:
PHP Version: OS:

 

 [2005-10-03 23:09 UTC] voidvoidpointer at yahoo dot com 
Description:
------------
Symptom:
"configure --with-gd" fails on dual AMD Opteron x86_64 
systems with Fedora Core 2 for php-4.3.11, php-4.4.0, 
and php-5.0.5 although it is possible to produce a 
working 64-bit php _without_ the GD extension.

Related Bugs:
Please refer to bug reports 31610, 33745, 32300.  
Unfortunately, those reports have been classified as 
"bogus" and the reports closed.  Nevertheless, there is 
a persistent problem described in this report.  The 
reason those reports were closed is that there wasn't 
enough information about the problem, but that is 
addressed by this report as well a possible solution.

Notes:
To gather data more easily, configure's first line was 
changed from "#! /bin/sh" to "#! /bin/sh -x", and every 
trial of configure was tried on a "clean slate" by 
running both "make clean" and "rm -f confdefs.h 
config.log config.nice config.cache config.status" after 
each trial.

Facts:
Directory /usr/lib64 is where libgd.so, libjpeg.so, 
libjpeg.a, libpng.so, and libpng.a reside, and directory 
/usr/include is where the header files are located.

Exhibit A (constant results for php-4.3.11, php-4.4.0, 
and php-5.0.5):

++ echo floorf
++ tr abcdefghijklmnopqrstuvwxyz 
ABCDEFGHIJKLMNOPQRSTUVWXYZ
+ ac_tr_func=HAVE_FLOORF
+ cat
+ test no = no
+ PHP_PNG_DIR=yes
+ test no = yes
+ test no = yes
+ test no '!=' no
+ echo 'If configure fails try --with-jpeg-dir=<DIR>'
If configure fails try --with-jpeg-dir=<DIR>
+ test yes '!=' no
+ test -f yes/lib/libpng.so -o -f yes/lib/libpng.a
+ test -f /usr/local/lib/libpng.so -o -f /usr/local/lib/
libpng.a
+ test -f /usr/lib/libpng.so -o -f /usr/lib/libpng.a
+ test -z ''
+ echo 'configure: error: libpng.(a|so) not found.'
configure: error: libpng.(a|so) not found.
+ exit 1

The message "error: libpng.(a|so) not found." appears in 
two places in the configure script.  The failure seen 
above is at the first location.

Exhibit B (results are equivalent for php-4.3.11, php
-4.4.0, and php-5.0.5):

++ echo floorf
++ tr abcdefghijklmnopqrstuvwxyz 
ABCDEFGHIJKLMNOPQRSTUVWXYZ
+ ac_tr_func=HAVE_FLOORF
+ cat
+ test no = no
+ PHP_PNG_DIR=yes
+ test no = yes
+ test no = yes
+ test /usr/lib64 '!=' no
+ test -f /usr/lib64/lib/libjpeg.so -o -f /usr/lib64/
lib/libjpeg.a
+ test -f /usr/local/lib/libjpeg.so -o -f /usr/local/
lib/libjpeg.a
+ test -f /usr/lib/libjpeg.so -o -f /usr/lib/libjpeg.a
+ test -z ''
+ echo 'configure: error: libjpeg.(a|so) not found.'
configure: error: libjpeg.(a|so) not found.
+ exit 1

The message "error: libjpeg.(a|so) not found." appears 
in three places in the configure script.  The failure 
seen above is at the second location.

Analysis of failures:

From Exhibit A, the lines

+ PHP_PNG_DIR=yes
+ test yes '!=' no

ensure that the test below which appears inside a for 
loop will always fail

+ test -f yes/lib/libpng.so -o -f yes/lib/libpng.a

That for loop is:
    for i in $PHP_PNG_DIR /usr/local /usr; do
        test -f $i/lib/libpng.$SHLIB_SUFFIX_NAME -o -f 
$i/lib/libpng.a && GD_PNG_DIR=$i && break
    done

Pathname "yes/lib/*" does not exist and is derived 
incorrectly.  There is one other similar for loop which 
also incorrectly appends the suffix "lib" to "yes".


From Exhibit B, the line

+ test /usr/lib64 '!=' no

implies that $PHP_JPEG_DIR was set to /usr/lib64, and
appending the suffix "lib" to "/usr/lib64" ensures that 
test below which appears inside a for loop will always 
fail because "/usr/lib64/lib" does not exist

+ test -f /usr/lib64/lib/libjpeg.so -o -f /usr/lib64/
lib/libjpeg.a

That for loop is:
    for i in $PHP_JPEG_DIR /usr/local /usr; do
        test -f $i/lib/libjpeg.$SHLIB_SUFFIX_NAME -o -f 
$i/lib/libjpeg.a && GD_JPEG_DIR=$i && break
    done

There are two other for loops which also incorrectly 
append the suffix "lib" to "/usr/lib64".

Of course, the line

+ PHP_PNG_DIR=yes

implies that the option --with-png-dir should be 
appended to those that were used to run Exhibit B, but 
when that is done, configure still fails, and the 
outputs are equivalent.

Exhibit C (a possible solution to the problem):

After removing those "lib" suffixes from configure, a 
few more iterations:

./configure --libdir=/usr/lib64 --with-gd --with-jpeg-
dir=/usr/lib64 --with-png-dir=/usr/lib64

yields the following

+ LDFLAGS= -Wl,-rpath,/usr/lib64/lib
+ LDFLAGS= -Wl,-rpath,/usr/lib64/lib -L/usr/lib64/lib
+ PHP_RPATHS= /usr/lib64/lib
+ LIBS=-ljpeg -lresolv -lm -ldl -lnsl  -lxml2 -lz -lm 
-lxml2 -lz -lm
+ test /usr/lib64 '!=' no
+ test -f /usr/lib64/libpng.so -o -f /usr/lib64/libpng.a
+ GD_PNG_DIR=/usr/lib64
+ break
+ test -z /usr/lib64
+ test no = no
+ echo 'configure: error: PNG support requires ZLIB. Use 
--with-zlib-dir=<DIR>'
configure: error: PNG support requires ZLIB. Use --with-
zlib-dir=<DIR>
+ exit 1

and

./configure --libdir=/usr/lib64 --with-gd --with-jpeg-
dir=/usr/lib64 --with-png-dir=/usr/lib64 --with-zlib

yields the following

+ LDFLAGS= -Wl,-rpath,/usr/lib64/lib
+ LDFLAGS= -Wl,-rpath,/usr/lib64/lib -L/usr/lib64/lib
+ PHP_RPATHS= /usr/lib64/lib
+ LIBS=-ljpeg -lz -lresolv -lm -ldl -lnsl  -lxml2 -lz 
-lm -lxml2 -lz -lm
+ test /usr/lib64 '!=' no
+ test -f /usr/lib64/libpng.so -o -f /usr/lib64/libpng.a
+ GD_PNG_DIR=/usr/lib64
+ break
+ test -z /usr/lib64
+ test /usr = no
+ test '!' -f /usr/lib64/include/png.h
+ echo 'configure: error: png.h not found.'
configure: error: png.h not found.
+ exit 1


After being set incorrectly in the for loop from Exhibit 
A,

+ GD_PNG_DIR=/usr/lib64

causes png.h to not be found in /usr/lib64/include/ 
because that is the wrong directory.  The correct 
pathname should be /usr/include/png.h.

Changing GD_PNG_DIR=/usr/lib64 to GD_PNG_DIR=/usr in 
that loop and

./configure --libdir=/usr/lib64 --with-gd --with-jpeg-
dir=/usr/lib64 --with-png-dir=/usr/lib64 --with-zlib=/
usr

leads to success and to a Makefile.

Conclusion:
There is something wrong with the configuration of the 
GD extension, and configure can be modified to do all of 
the steps that I performed manually on three separate 
releases of php:  php-4.3.11, php-4.4.0, and php-5.0.5.

I read http://www.fabnat.com/linux/Php4_FC4_x86_64.html 
just after I started working on this problem.  I used 
the ideas, but I did not try out the patch although 
maybe you folks should look at it as a start toward a 
solution.


Expected result:
----------------
A Makefile.

Actual result:
--------------
No Makefile.  Script configure did not finish.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-10-03 23:57 UTC] tony2001@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip
 [2005-10-04 02:16 UTC] voidvoidpointer at yahoo dot com 
I brought down the snapshot and tried to run configure.

The configure script failed and did not generate a 
Makefile.

For details of exactly how it failed, please refer to my 
initial post.

Did you tell me to try the snapshot because you knew 
that a change was made to the GD extension's 
configuration files?
 [2005-10-04 08:26 UTC] sniper@php.net 
Latest CVS (php5.1) works fine for me. You're doing something wrong. (propably not passing --with-libdir=lib64 to configure)
 [2005-10-04 13:59 UTC] voidvoidpointer at yahoo dot com 
sniper suggested:
./configure --with-libdir=lib64 --with-gd .

Is it not the function of the configure script to blur 
the differences between systems to aid installation by 
avoiding the tweaking of makefiles?

The current state of php's configure with the GD 
extension requires tweaking of configure's options 
before the Makefile is even generated.

That's a return to the days of makefiles without 
configure to generate them.

sniper's suggestion along with snapshot php5
-200510041030 produced:

+ echo 'If configure fails try --with-jpeg-dir=<DIR>'
If configure fails try --with-jpeg-dir=<DIR>
+ test yes '!=' no
+ test -f yes/lib64/libpng.so -o -f yes/lib64/libpng.a
+ test -f /usr/local/lib64/libpng.so -o -f /usr/local/
lib64/libpng.a
+ test -f /usr/lib64/libpng.so -o -f /usr/lib64/libpng.a
+ GD_PNG_DIR=/usr
+ break
+ test -z /usr
+ test no = no
+ echo 'configure: error: PNG support requires ZLIB. Use 
--with-zlib-dir=<DIR>'
configure: error: PNG support requires ZLIB. Use --with-
zlib-dir=<DIR>
+ exit 1
 [2005-10-04 14:09 UTC] tony2001@php.net 
So did you try to use --with-zlib-dir=<DIR> ?
Does it work for you?
 [2005-10-04 14:20 UTC] voidvoidpointer at yahoo dot com 
sniper's suggestion with php-5.1.0RC1 when evolved 
through configure's "hints":
./configure  --with-libdir=lib64  --with-gd --with-
zlib=/usr --with-xmlrpc

Congratulations, for php-5.1.0RC1, that generates a 
Makefile, but what is the fix for php-4.4.0 or even php
-4.3.11?
 [2005-10-04 14:34 UTC] tony2001@php.net 
PHP supports 64-bit OSes correctly starting from 5.1.
We won't backport it to 4.4.x and 5.0.x, since they are bugfix-only branches.
And 4.3.x branch is officially dead and replaced by 4.4.x.
 [2005-10-04 18:00 UTC] voidvoidpointer at yahoo dot com 
> PHP supports 64-bit OSes correctly starting from 5.1.

Thanks, but you should consider smartening up the GD extension's configuration files to require fewer command line tweaks from the user instead of more.

However, at this time, there is no blessed php-5.1 release; all there is today is php-5.1 Release Candidate while there is still much code which has yet to be ported from php-4 to php-5 or even just tested with php-5.

> We won't backport it to 4.4.x and 5.0.x, since they are bugfix-only branches.

OK... I understand why you are doing that.

For those who may find the same problem that I described, who may not be able to use php-5.1, and who need a php-4.4.x on a Fedora x86_64 machine,

the configure command that I used was:
./configure  --libdir=/usr/lib64  --with-apxs2=/usr/local/apache2/bin/apxs  --with-mysql=/usr/local --with-curl  --with-gdbm  --with-zlib  --enable-calendar  --with-png-dir  --with-gdbm  --enable-calendar  --enable-exif  --with-tiff-dir  --with-readline --enable-sockets  --with-pear  --enable-yp  --with-gd  --with-freetype-dir  --enable-gd-native-ttf  --enable-gd-imgstrttf  --with-jpeg-dir  --with-png-dir  --with-zlib  --enable-mbstring

and a diff that documents what I changed in php-4.4.0/configure file to enable it to correctly generate a Makefile follows:

my$ diff php-4.4.0/configure myhacked_php-4.4.0/configure
1c1
< #! /bin/sh
---
> #! /bin/sh -x
19935c19935
<       if test -f "$i/lib/libjpeg.$SHLIB_SUFFIX_NAME" -o -f "$i/lib/libjpeg.a"; then
---
>       if test -f "$i/libjpeg.$SHLIB_SUFFIX_NAME" -o -f "$i/libjpeg.a"; then
31480c31480
<       test -f $i/lib/libjpeg.$SHLIB_SUFFIX_NAME -o -f $i/lib/libjpeg.a && GD_JPEG_DIR=$i && break
---
>       test -f $i/libjpeg.$SHLIB_SUFFIX_NAME -o -f $i/libjpeg.a && GD_JPEG_DIR=$i && break
31755c31755
<       test -f $i/lib/libpng.$SHLIB_SUFFIX_NAME -o -f $i/lib/libpng.a && GD_PNG_DIR=$i && break
---
>       test -f $i/libpng.$SHLIB_SUFFIX_NAME -o -f $i/libpng.a && GD_PNG_DIR=/usr && break
33276c33276
<       test -f $i/lib/libjpeg.$SHLIB_SUFFIX_NAME -o -f $i/lib/libjpeg.a && GD_JPEG_DIR=$i && break
---
>       test -f $i/libjpeg.$SHLIB_SUFFIX_NAME -o -f $i/libjpeg.a && GD_JPEG_DIR=$i && break
33551c33551
<       test -f $i/lib/libpng.$SHLIB_SUFFIX_NAME -o -f $i/lib/libpng.a && GD_PNG_DIR=$i && break
---
>       test -f $i/libpng.$SHLIB_SUFFIX_NAME -o -f $i/libpng.a && GD_PNG_DIR=/usr && break
my$ 

That allowed me to build what I needed, but note that it is a particularly artless hack.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Dec 21 16:01:28 2024 UTC