Re: Bug #12607 Updated: new autoconf 2.52 does not work with latest CVS.

--- Jani Taskinen <sniper@iki.fi> wrote: > > Please try latest CVS. Let me know if it works for you. > Get a fresh checkout. And don't apply any patches.. just did a cvs checkout of the latest CVS. # ./buildconf buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4 (ok) buildconf: libtool version 1.4a (ok) rebuilding Makefile templates automake: configure.in: installing `Zend/ylwrap' rebuilding configure rebuilding acconfig.h rebuilding main/php_config.h.in export LIBS="-lm -liconv -lc -lintl -lX11" && \ export LDFLAGS="-Wl,-export-dynamic \ -Wl,-R/usr/lib -L/usr/lib \ -Wl,-R/usr/pkg/lib -L/usr/pkg/lib \ -Wl,-R/usr/local/lib -L/usr/local/lib \ -Wl,-R/usr/X11R6/lib -L/usr/X11R6/lib" ./configure \ --with-sablot=/usr/local/install/Sablot-0.52 \ --with-expat-dir=/usr/local \ --with-iconv=/usr/pkg \ --disable-pear \ --with-gd=/usr/pkg \ --enable-gd-native-ttf \ --with-png-dir=/usr/pkg \ --with-jpeg-dir=/usr/pkg \ --with-xpm-dir=/usr/X11R6 \ --with-pgsql=/usr/local \ --with-mysql=/usr/local \ --enable-libgcc \ --with-gnu-ld \ --with-zlib \ --with-system-regex \ --with-config-file-path=/usr/local/etc \ --enable-track-vars \ --enable-force-cgi-redirect \ --enable-discard-path \ --enable-memory-limit \ --enable-sysvsem \ --enable-sysvshm \ --enable-sockets ... Configuring libtool checking build system type... alpha-unknown-netbsd1.5W checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking how to recognise dependant libraries... match_pattern /lib[^/\.]+\.so$ checking for object suffix... o checking for executable suffix... no checking for ranlib... (cached) ranlib checking for strip... strip updating cache ./config.cache /bin/sh: Can't open ./ltconfig configure: error: libtool configure failed looks like this libtool won't work with NetBSD/Alpha-1.5W. let's try using the latest libtool from NetBSD's package collection: # cp -R /usr/pkg/bin/libtool /usr/pkg/share/libtool/* ./ # ls -l libtool -r-xr-xr-x 1 root users 175020 Aug 19 22:41 libtool # rm config.cache ... run same configure as above ... we get the happy greeting: "Thank you for using PHP." NOTE: during the "Configuring libtool" process, there was this error: ... creating libtool updating cache ./config.cache loading cache ./config.cache loading cache ./config.cache within ltconfig checking host system type... alpha-unknown-netbsd1.5W checking build system type... alpha-unknown-netbsd1.5W -E: not found ltcf-cxx.sh: error: problem compiling test program # ls -l libtool -rwxr-xr-x 1 root users 174702 Aug 19 22:45 libtool yep configure build a new libtool. filesize is smaller. let's use the libtool from NetBSD's package collection because of the error above. if we use this newly created libtool, we'll get the error about "... not a libtool object" later on. copy it over again: # mv libtool libtool.bak # cp /usr/pkg/bin/libtool ./ # pwd /usr/local/source/php/php4-current/php4 #gmake ... /bin/sh /usr/local/source/php/php4-current/php4/libtool --silent --mode=link gcc -I. -I/usr/local /source/php/php4-current/php4/main -I/usr/local/source/php/php4-current/php4/main -I/usr/local/so urce/php/php4-current/php4 -I/usr/local/source/php/php4-current/php4/Zend -I/usr/pkg/include -I/u sr/local/include/mysql -I/usr/local/include -I/usr/local/install/Sablot-0.52/include -I/usr/pkg/ include -I/usr/local/source/php/php4-current/php4/TSRM -g -O2 -Wl,-export-dynamic -Wl,-R/usr/l ib -L/usr/lib -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -Wl,-R/usr/local/lib -L/usr/local/lib -Wl,- R/usr/X11R6/lib -L/usr/X11R6/lib -o libmain.la main.lo internal_functions.lo snprintf.lo php_spr intf.lo safe_mode.lo fopen_wrappers.lo alloca.lo php_ini.lo SAPI.lo rfc1867.lo php_content_types. lo strlcpy.lo strlcat.lo mergesort.lo reentrancy.lo php_variables.lo php_ticks.lo streams.lo netw ork.lo php_open_temporary_file.lo php_logos.lo output.lo libtool: link: `main.lo' is not a valid libtool object gmake[2]: *** [libmain.la] Error 1 gmake[2]: Leaving directory `/usr/local/source/php/php4-current/php4/main' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/local/source/php/php4-current/php4/main' gmake: *** [all-recursive] Error 1 i guess NetBSD's libtool didn't work well. let's try to go back to the one created by configure: #gmake clean ... # mv libtool.bak libtool #gmake ... /bin/sh /usr/local/source/php/php4-current/php4/libtool --silent --mode=link gcc -I. -I/usr/local /source/php/php4-current/php4/main -I/usr/local/source/php/php4-current/php4/main -I/usr/local/so urce/php/php4-current/php4 -I/usr/local/source/php/php4-current/php4/Zend -I/usr/pkg/include -I/u sr/local/include/mysql -I/usr/local/include -I/usr/local/install/Sablot-0.52/include -I/usr/pkg/ include -I/usr/local/source/php/php4-current/php4/TSRM -g -O2 -Wl,-export-dynamic -Wl,-R/usr/l ib -L/usr/lib -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -Wl,-R/usr/local/lib -L/usr/local/lib -Wl,- R/usr/X11R6/lib -L/usr/X11R6/lib -o libmain.la main.lo internal_functions.lo snprintf.lo php_spr intf.lo safe_mode.lo fopen_wrappers.lo alloca.lo php_ini.lo SAPI.lo rfc1867.lo php_content_types. lo strlcpy.lo strlcat.lo mergesort.lo reentrancy.lo php_variables.lo php_ticks.lo streams.lo netw ork.lo php_open_temporary_file.lo php_logos.lo output.lo libtool: link: `main.lo' is not a valid libtool object gmake[2]: *** [libmain.la] Error 1 gmake[2]: Leaving directory `/usr/local/source/php/php4-current/php4/main' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/local/source/php/php4-current/php4/main' gmake: *** [all-recursive] Error 1 ARGH! the snap worked perfectly though. > > --Jani > > > > On Fri, 17 Aug 2001, Caffeinate The World wrote: > > > > >--- Jani Taskinen <sniper@iki.fi> wrote: > >> On 17 Aug 2001 mochaexpress@yahoo.com wrote: > >> > >> >then i applied this patch i sent in before, but it looks like it > >> didn't make it to cvs yet: > >> > > >> > --- iconv/config.m4.orig Mon Jun 25 08:42:44 2001 > >> > +++ iconv/config.m4 Mon Jun 25 09:30:37 2001 > >> > @@ -29,7 +29,7 @@ > >> > > >> > if test -e $ICONV_DIR/lib/libconv.a -o -e > >> $ICONV_DIR/lib/libiconv.so ; then > >> > PHP_ADD_LIBRARY_WITH_PATH(iconv, $ICONV_DIR/lib, > >> ICONV_SHARED_LIBADD) > >> > - AC_CHECK_LIB(iconv, iconv_open, AC_DEFINE(HAVE_ICONV, 1, > [ > >> ])) > >> > + AC_CHECK_LIB(iconv, libiconv_open, > AC_DEFINE(HAVE_LIBICONV, > >> 1, [ ])) > >> > else > >> > AC_CHECK_LIB(c, iconv_open, AC_DEFINE(HAVE_ICONV, 1, [ > ])) > >> > fi > >> > >> I changed this. > >> > >> > --- sablot/config.m4.orig Mon Jun 25 10:10:56 2001 > >> > +++ sablot/config.m4 Mon Jun 25 10:10:22 2001 > >> > @@ -49,7 +49,11 @@ > >> > fi > >> > > >> > found_iconv=no > >> > - AC_CHECK_LIB(c, iconv_open, found_iconv=yes) > >> > + if test -e $ICONV_DIR/lib/libconv.a -o -e > >> $ICONV_DIR/lib/libiconv.so ; then > >> > + AC_CHECK_LIB(iconv, libiconv_open, found_iconv=yes) > >> > + else > >> > + AC_CHECK_LIB(c, iconv_open, found_iconv=yes) > >> > + fi > >> > if test "$found_iconv" = "no"; then > >> > if test "$PHP_ICONV" = "no"; then > >> > for i in /usr /usr/local; do > >> > --- xslt/config.m4.orig Mon Jun 25 10:11:57 2001 > >> > +++ xslt/config.m4 Mon Jun 25 10:13:13 2001 > >> > @@ -65,7 +65,11 @@ > >> > fi > >> > > >> > found_iconv=no > >> > - AC_CHECK_LIB(c, iconv_open, found_iconv=yes) > >> > + if test -e $ICONV_DIR/lib/libconv.a -o -e > >> $ICONV_DIR/lib/libiconv.so ; then > >> > + AC_CHECK_LIB(iconv, libiconv_open, found_iconv=yes) > >> > + else > >> > + AC_CHECK_LIB(c, iconv_open, found_iconv=yes) > >> > + fi > >> > if test "$found_iconv" = "no"; then > >> > if test "$PHP_ICONV" = "no"; then > >> > for i in /usr /usr/local; do > >> > > >> > >> why would you need these two config.m4 to be changed ?? > > > >the reason was xslt and sablot need to find iconv. on my system the > >functions preceeds with 'lib...' so w/o my patch above it will fail > to > >detect the existence of iconv. consequently, if i configure with > sablot > >and/or xslt, it will fail during the configure phase giving the > error > >that it couldn't find iconv. > > > >> What errors do you get if you don't apply the patch? > >see above. > > > >> > >> --Jani > >> > >> p.s. GD problem: Something is causing the configure to detect that > >> you > >> have freetype support in your gd-lib, but it doesn't have it.. > > > >yes i got that figured out. my package version of gd was compiled > with > >ft1.8x instead of ft2.x, but ft2.x is installed on my system. as a > >result php detected it and decided to use it.. via my configure > option > >to it. i've since removed the ft/ttf options and was able to finish > >with the make process. > > > >IMPORTANT: i submited another bug # 11707 a while back, it was > >critical. testing the snap, it seems as though that bug has been > fixed. > >you may want to close it. however, i've yet to verify compile from > CVS, > >just the snap thus far. > > > >> >./.libs/libphp4.a(gd.o): In function `php_imagettftext_common': > >> > >>/home/staffs/t/tom/work/php/php4-current/snap/php4-200108162235/ext/gd/gd.c:2748: > >> undefined refer > >> >ence to `gdImageStringFT' > >> > >>/home/staffs/t/tom/work/php/php4-current/snap/php4-200108162235/ext/gd/gd.c:2748: > >> undefined refer > >> >ence to `gdImageStringFT' > >> >collect2: ld returned 1 exit status > >> >gmake[1]: *** [php] Error 1 > >> >gmake[1]: Leaving directory > >> `/home/staffs/t/tom/work/php/php4-current/snap/php4-200108162235' > >> >gmake: *** [all-recursive] Error 1 > >> > > >> >--- but i think that is a diff problem altoghether. you probably > >> could > >> >close this now. we can open a new one for gd :) > >> > > >> > > > > > >__________________________________________________ > >Do You Yahoo!? > >Make international calls for as low as $.04/minute with Yahoo! > Messenger > >http://phonecard.yahoo.com/ > > > > > __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/