From: voidvoidpointer at yahoo dot com
Operating system: Fedora Core 2 x86_64
PHP version: 5.0.5
PHP Bug Type: GD related
Bug description: configure is confused by 64bit x86_64 on Fedora
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.
--
Edit bug report at http://bugs.php.net/?id=34722&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34722&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34722&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34722&r=trysnapshot51
Fixed in CVS: http://bugs.php.net/fix.php?id=34722&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=34722&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34722&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34722&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34722&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34722&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34722&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34722&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34722&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=34722&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34722&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=34722&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34722&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34722&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34722&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34722&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34722&r=mysqlcfg
