ID: 34722 Updated by: [EMAIL PROTECTED] Reported By: voidvoidpointer at yahoo dot com -Status: Open +Status: Bogus Bug Type: GD related Operating System: Fedora Core 2 x86_64 PHP Version: 5.0.5 New Comment:
Latest CVS (php5.1) works fine for me. You're doing something wrong. (propably not passing --with-libdir=lib64 to configure) Previous Comments: ------------------------------------------------------------------------ [2005-10-04 02:16:47] 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-03 23:57:23] [EMAIL PROTECTED] 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-03 23:09:57] 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. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=34722&edit=1
