ID: 34722 Updated by: [EMAIL PROTECTED] Reported By: voidvoidpointer at yahoo dot com -Status: Open +Status: Feedback Bug Type: GD related Operating System: Fedora Core 2 x86_64 PHP Version: 5.0.5 New Comment:
So did you try to use --with-zlib-dir=<DIR> ? Does it work for you? Previous Comments: ------------------------------------------------------------------------ [2005-10-04 13:59:32] 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 08:26:34] [EMAIL PROTECTED] Latest CVS (php5.1) works fine for me. You're doing something wrong. (propably not passing --with-libdir=lib64 to configure) ------------------------------------------------------------------------ [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
