PHP 4.0 Bug #9898 Updated: gd and mck fail to link but did in 4.0.4pl1

ID: 9898 Updated by: wez Reported By: wez@php.net Old-Status: Open Status: Bogus Bug Type: Compile Problem Assigned To: Comments: Completely clean CVS checkout fixes problem --> Bogus. Sorry for wasting your time Jani. --Wez. Previous Comments: --------------------------------------------------------------------------- [2001-03-23 10:57:10] wez@php.net On 2001-03-23 13:00:49, Jani Taskinen <sniper@iki.fi> wrote: > On 22 Mar 2001 wez@php.net wrote: > jstring? > dbg ?? > mailparse? mbregex? > savi? jstring and mbregex are extensions that provide support for MBCS; part of a toolkit for supporting Japanese text in PHP. dbg is a zend extension for debugging PHP, freely available from http://dd.cron.ru/dbg/ mailparse is an extension based on the rfc2045 and rfc822 libraries from maildrop, which is part of the courier mail server. savi is an interface to the Sophos Anti Virus library. I wrote the last two - I don't think any of these are responsible for the build problems, as they work just fine and have done for some time. > >Likewise, if I enable cybercash support it also breaks. > >It doesn't seem to be related to the config.m4 files for those > >extensions, but does seem to be a problem with linking static libraries. > > Hmm.. > > >Nothing has changed on my system since the last successful compile of > >CVS PHP (around the time preg_replace_callback was implemented). Actually, the only thing that changed was that I installed the mhash library, but I don't think that has caused the problem. > ..so you don't know exactly when this started happening? > Could it be after the fastcgi was added in? My last completely successful build was just before some build files were broken; there were a couple of posts to the dev list about it. Specifically, it was just after preg_replace_callback was implemented - I know this because I discovered a bug in the interaction between preg_replace and the zend_is_callable function. Yes, this was before the fastcgi sapi was added. > Anything odd in config.log ? No, nothing strange - the gd tests compile/complete successfully during configure. > >So I have a feeling that it is something to do with the main build files somewhere... > >Most strange! > Yes it is. As it works for me just fine.. :) I will try building with a completely fresh CVS checkout to see if that makes any difference. --------------------------------------------------------------------------- [2001-03-22 09:01:34] wez@php.net Sorry - I should have been more verbose. Yes, I did cvsclean and buildconf a number of times, tried manually deleting the config.cache too, but no go. I'm currently using: './configure' '--with-apxs' '--disable-pear' '--enable-debug' '--enable-sigchild' '--enable-calendar' '--enable-ftp' '--with-ldap' '--with-mysql=/usr' '--enable-shmop' '--enable-sysvsem' '--enable-sysvshm' '--with-zlib' '--enable-inline-optimization' '--with-curl' '--with-iconv' '--with-bz2' '--with-gettext' '--enable-sockets' '--enable-wddx' '--enable-jstring' '--with-openssl' '--enable-bcmath' '--enable-ctype' '--enable-dbg' '--with-imap' '--enable-mailparse' '--enable-mbregex' '--with-pspell' '--with-recode' '--with-savi=/home/CLIENTWEB/sophosantivirus/sav_if' '--enable-yp' '--without-gd' '--with-mhash' If I change it to use --with-gd, configure detects libgd.a: checking whether to enable truetype string function in gd... no checking for libjpeg (needed by gd-1.8+)... no configure: warning: If configure fails try --with-jpeg-dir=<DIR> checking for libXpm (needed by gd-1.8+)... no configure: warning: If configure fails try --with-xpm-dir=<DIR> checking whether to include GD support... yes (static) checking for gdImageString16 in -lgd... yes checking for gdImagePaletteCopy in -lgd... yes checking for gdImageColorClosestHWB in -lgd... yes checking for compress in -lz... yes checking for png_info_init in -lpng... yes checking for gdImageColorResolve in -lgd... yes checking for gdImageCreateFromPng in -lgd... yes checking for gdImageCreateFromGif in -lgd... no checking for gdImageWBMP in -lgd... yes checking for gdImageCreateFromJpeg in -lgd... no checking for gdImageCreateFromXpm in -lgd... yes checking whether to include FreeType 1.x support... yes Likewise, if I enable cybercash support it also breaks. It doesn't seem to be related to the config.m4 files for those extensions, but does seem to be a problem with linking static libraries. Nothing has changed on my system since the last successful compile of CVS PHP (around the time preg_replace_callback was implemented). So I have a feeling that it is something to do with the main build files somewhere... Most strange! --------------------------------------------------------------------------- [2001-03-21 15:30:32] sniper@php.net I guess you know enough to do './cvsclean ; ./buildconf' after updating CVS ? And what was the configure line used? --Jani --------------------------------------------------------------------------- [2001-03-21 07:42:43] wez@php.net Weird - can't find my duplicate report, so reopened this one. I'm having problems with the bug system - it's slow to react and seems to hang. Anyway, I left this information out: /bin/sh /home/wez/source/phpbuild/libtool --silent --mode=link gcc -I. -I/home/wez/source/phpbuild/ -I/home/wez/source/phpbuild/main -I/home/wez/source/phpbuild -I/usr/include/apache -I/home/wez/source/phpbuild/Zend -I/usr/local/include -I/usr/local/mck-3.2.0.3-linux//c-api -I/usr/include/freetype -I/usr/include/gd -I/usr/include/imap -I/usr/include/mysql -I/usr/local/include/pspell -I/home/CLIENTWEB/sophosantivirus/sav_if -I/home/wez/source/phpbuild/ext/xml/expat/xmltok -I/home/wez/source/phpbuild/ext/xml/expat/xmlparse -I/home/wez/source/phpbuild/TSRM -DEAPI_MM -DLINUX=2 -DMOD_SSL=206105 -DUSE_HSREGEX -DEAPI -DUSE_EXPAT -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g -O2 -o libphp4.la -rpath /home/wez/source/phpbuild/libs -avoid-version -L/usr/local/lib -L/usr/local/mck-3.2.0.3-linux//c-api/lib -L/usr/lib/mysql -R /usr/local/lib -R /usr/local/mck-3.2.0.3-linux//c-api/lib -R /usr/lib/mysql stub.lo Zend/libZend.la sapi/apache/libsapi.la main/libmain.la regex/libregex.la ext/bz2/libbz2.la ext/calendar/libcalendar.la ext/curl/libcurl.la ext/cybercash/libcybercash.la ext/dbg/libdbg.la ext/ftp/libftp.la ext/gd/libgd.la ext/gettext/libgettext.la ext/iconv/libiconv.la ext/imap/libimap.la ext/jstring/libjstring.la ext/ldap/libldap.la ext/mailparse/libmailparse.la ext/mbregex/libmbregex.la ext/mhash/libmhash.la ext/mysql/libmysql.la ext/pcre/libpcre.la ext/posix/libposix.la ext/pspell/libpspell.la ext/savi/libsavi.la ext/session/libsession.la ext/shmop/libshmop.la ext/sockets/libsockets.la ext/standard/libstandard.la ext/sysvsem/libsysvsem.la ext/sysvshm/libsysvshm.la ext/wddx/libwddx.la ext/xml/libxml.la ext/yp/libyp.la ext/zlib/libzlib.la TSRM/libtsrm.la -lpam -lsavi -lc-client -ldl -lz -lpspell -lmysqlclient -lmhash -lldap -llber -lttf -lz -lpng -lgd -lmckcrypto -lcurl -lbz2 -lresolv -lm -ldl -lcrypt -lnsl -lresolv --------------------------------------------------------------------------- [2001-03-21 07:38:21] wez@php.net Sorry - forgot some info which is in the other report. I'm having B/W problems so the bug system is reacting slowly for me... --------------------------------------------------------------------------- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9898&edit=2