#21735 [NEW]: errors in mcve.c on make
From: [EMAIL PROTECTED] Operating system: FreeBSD 4.6 PHP version: 4.3.0 PHP Bug Type: Compile Failure Bug description: errors in mcve.c on make The error I get on make: /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c: In function `zm_startup_mcve': /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:165: `MC_TRANTYPE' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:165: (Each undeclared identifier is reported only once /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:165: for each function it appears in.) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:166: `MC_USERNAME' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:167: `MC_PASSWORD' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:168: `MC_ACCOUNT' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:169: `MC_TRACKDATA' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:170: `MC_EXPDATE' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:171: `MC_STREET' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:172: `MC_ZIP' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:173: `MC_CV' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:174: `MC_COMMENTS' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:175: `MC_CLERKID' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:176: `MC_STATIONID' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:177: `MC_APPRCODE' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:178: `MC_AMOUNT' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:179: `MC_PTRANNUM' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:180: `MC_TTID' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:181: `MC_USER' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:182: `MC_PWD' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:183: `MC_ACCT' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:184: `MC_BDATE' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:185: `MC_EDATE' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:186: `MC_BATCH' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:187: `MC_FILE' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:188: `MC_ADMIN' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:189: `MC_AUDITTYPE' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:190: `MC_CUSTOM' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:193: `MC_USER_PROC' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:194: `MC_USER_USER' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:195: `MC_USER_PWD' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:196: `MC_USER_INDCODE' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:197: `MC_USER_MERCHID' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:198: `MC_USER_BANKID' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:199: `MC_USER_TERMID' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:200: `MC_USER_CLIENTNUM' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:201: `MC_USER_STOREID' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:202: `MC_USER_AGENTID' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:203: `MC_USER_CHAINID' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:204: `MC_USER_ZIPCODE' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mcve.c:205: `MC_USER_TIMEZONE' undeclared (first use in this function) /usr/home/klimpong/download/php-4.3.0/ext/mcve/mc
#21200 [NEW]: --with-mssql doesn't work
From: [EMAIL PROTECTED] Operating system: linux (Linux sdesktop 2.4.18-4GB #1 Wed Mar 27 13:57:05 UTC 2002 i686 unknown) PHP version: 4.2.3 PHP Bug Type: MSSQL related Bug description: --with-mssql doesn't work I tried to ./configure PHP with "./configure --with-apxs --with-mysql --with-mssql" but it doesn't pick up the latter. I also tried "--with-mssql=/home/user/freetds-0.60" or "--with-mssql=/home/user/freetds-0.60/src". It just doesn't recognize the "--with-mssql" part. I removed the comment from php.ini (which is placed in /usr/local/lib and found by phpinfo()) anyways, but no luck. The manual backs up my "--with-mssql" theory. But no luck. Whatever options I put to "./configure" it works. Strangly that it doesn't list "--with-mssql" when I do a "./configure --help" Thanks, Till -- Edit bug report at http://bugs.php.net/?id=21200&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21200&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21200&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21200&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21200&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21200&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21200&r=support Expected behavior: http://bugs.php.net/fix.php?id=21200&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21200&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21200&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21200&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21200&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21200&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21200&r=isapi
#21200 [Csd]: --with-mssql doesn't work
ID: 21200 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: MSSQL related Operating System: linux (Linux sdesktop 2.4.18-4GB PHP Version: 4.2.3 New Comment: Thank you. Previous Comments: [2002-12-26 12:35:07] [EMAIL PROTECTED] --with-mssql is only available from PHP 4.3.0. You can use a cvs snapshot or RC4. [2002-12-26 10:41:19] [EMAIL PROTECTED] I tried to ./configure PHP with "./configure --with-apxs --with-mysql --with-mssql" but it doesn't pick up the latter. I also tried "--with-mssql=/home/user/freetds-0.60" or "--with-mssql=/home/user/freetds-0.60/src". It just doesn't recognize the "--with-mssql" part. I removed the comment from php.ini (which is placed in /usr/local/lib and found by phpinfo()) anyways, but no luck. The manual backs up my "--with-mssql" theory. But no luck. Whatever options I put to "./configure" it works. Strangly that it doesn't list "--with-mssql" when I do a "./configure --help" Thanks, Till -- Edit this bug report at http://bugs.php.net/?id=21200&edit=1
#48775 [Opn]: php-5.2.10 treats include_path as url/hostname
ID: 48775
Updated by: t...@php.net
Reported By: alexander at sulfrian dot net
Status: Open
Bug Type: Streams related
Operating System: Linux
PHP Version: 5.2.10
New Comment:
Because I work on RoundCube, I double-checked this bug submission.
Just compiled PHP 5.2.10 from source with this:
./configure --with-mysql --enable-fastcgi --enable-force-cgi-redirect
make
And then put the "sapi/cgi/php-cgi" into the webserver as the fcgi
binary it uses to serve PHP to test it. And, absolutely no issues.
It seems to me like the Gentoo packages are borked. I suggest you guys
verify that it works for you when you compile PHP from source.
Previous Comments:
[2009-07-03 14:09:01] bugs+php at nospam dot obeliks dot de
I can confirm that I'm having the same problem with php-5.2.10 on
Gentoo linux.
Here it occurs with Horde Webmail, which uses the following call to
change the include_path (which worked fine on any previous version of
php):
> ini_set('include_path', dirname(__FILE__) . PATH_SEPARATOR .
dirname(__FILE__) . '/../pear');
[2009-07-03 08:59:52] alexander at sulfrian dot net
Noticed while trying to install roundcube webmail 0.2.0. I just tried
to create a minimal testing script and didn't get it.
One strange thing is, that if i call the script via php cli from shell,
it is working. Don't know how i could debug it. roundcube using the
__autoload function and all includes seems to be ok. Is there any
possibility to echo the hostname, that could not be resolved if such
error occur?
I am using Gentoo Linux and so installed php from source via the
portage system of gentoo. I not changed the config and so used the
original that is installed by gentoo. (Do not know if it is 100%
identical to the original from the php source package.)
[2009-07-02 15:17:23] j...@php.net
What scripts..? When you install PHP from sources, any existing ini
files ARE NOT TOUCHED. Did you use some RPM or what?
[2009-07-02 13:22:13] alexander at sulfrian dot net
Description:
Hi,
I updated recently to php-5.2.10 and some scripts are not working
anymore. The scripts added some elements to the include_path. While
including some files from the include_path php echos the error that it
cannot resolve the host name. I think that this error is caused by the
change, that stream wrappers could be used in the include path and the
PATH_SEPERATOR and the stream wrappers collidate.
Downgrading to php-5.2.9-r2 solves the problem again.
Actual result:
--
[02-Jul-2009 13:21:47] PHP Warning: require() [function.require]: Couldn't resolve host
name in on line
[02-Jul-2009 13:21:47] PHP Warning: require(rcube_user.php) [function.require]: failed to open stream:
operation failed in on line
--
Edit this bug report at http://bugs.php.net/?id=48775&edit=1
#49682 [Asn]: Pear broken in php 5.2.11
ID: 49682 Updated by: t...@php.net Reported By: kr_krack at yahoo dot com Status: Assigned Bug Type: Compile Failure Operating System: Ubuntu 8.04 LTS PHP Version: 5.2.11 Assigned To: dufuz New Comment: Hey guys, please confirm the following: ./configure -prefix=/till-test --disable-rpath --disable-ipv6 -- disable-pdo --disable-debug --with-bz2=/usr --with-zlib-dir=/usr -- with-pcre-regex --with-mhash --with-xsl=/usr --with-mcrypt=/usr -- enable-mbstring --enable-inline-optimization --enable-xml --enable- sockets --enable-mbregex --enable-zip --enable-cli make make install It started working when I removed --with-zend-vm=GOTO. Thanks, Till Previous Comments: [2009-10-28 16:14:47] saltybea...@php.net Have you tried the latest install-pear-nozlib.phar? Available here: http://pear.php.net/install-pear-nozlib.phar [2009-10-27 12:20:24] cel...@php.net Pierre: I have a newborn, I reassigned this to dufuz because I won't have time to fix this in any reasonable timeframe [2009-10-27 07:14:28] jcua at shaw dot ca I have the same errors compiling php5.2.11 on centos 5.4 with apache 2.2.14 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1400 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1400 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1400 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1400 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1400 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1400 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1400 [2009-09-27 02:54:30] j...@php.net Assigned to the PEAR maintainer. [2009-09-26 18:58:39] kr_krack at yahoo dot com Description: I just compiled php 5.2.11, it seems that pear is broken again in this version, like in php 5.2.10. Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.pha r/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.pha r/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.pha r/PEAR/ChannelFile.php on line 1400 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.pha r
#49682 [Asn]: Pear broken in php 5.2.11
ID: 49682 Updated by: t...@php.net Reported By: kr_krack at yahoo dot com Status: Assigned Bug Type: Compile Failure Operating System: Ubuntu 8.04 LTS PHP Version: 5.2.11 Assigned To: dufuz New Comment: For the sake of completeness: r...@always:~/php-5.2.11# make install Installing PHP SAPI module: cgi Installing PHP CGI binary: /till-test/bin/ Installing PHP CLI binary:/till-test/bin/ Installing PHP CLI man page: /till-test/man/man1/ Installing build environment: /till-test/lib/php/build/ Installing header files: /till-test/include/php/ Installing helper programs: /till-test/bin/ program: phpize program: php-config Installing man pages: /till-test/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /till-test/lib/php/ [PEAR] Archive_Tar- already installed: 1.3.3 [PEAR] Console_Getopt - already installed: 1.2.3 [PEAR] Structures_Graph- already installed: 1.0.2 [PEAR] XML_Util - already installed: 1.2.1 [PEAR] PEAR - already installed: 1.8.0 Wrote PEAR system config file at: /till-test/etc/pear.conf You may want to add: /till-test/lib/php to your php.ini include_path I used php-5.2.11 from php.net. No additional patches (fpm), etc.. Previous Comments: [2009-10-28 16:32:01] t...@php.net Hey guys, please confirm the following: ./configure -prefix=/till-test --disable-rpath --disable-ipv6 -- disable-pdo --disable-debug --with-bz2=/usr --with-zlib-dir=/usr -- with-pcre-regex --with-mhash --with-xsl=/usr --with-mcrypt=/usr -- enable-mbstring --enable-inline-optimization --enable-xml --enable- sockets --enable-mbregex --enable-zip --enable-cli make make install It started working when I removed --with-zend-vm=GOTO. Thanks, Till [2009-10-28 16:14:47] saltybea...@php.net Have you tried the latest install-pear-nozlib.phar? Available here: http://pear.php.net/install-pear-nozlib.phar [2009-10-27 12:20:24] cel...@php.net Pierre: I have a newborn, I reassigned this to dufuz because I won't have time to fix this in any reasonable timeframe [2009-10-27 07:14:28] jcua at shaw dot ca I have the same errors compiling php5.2.11 on centos 5.4 with apache 2.2.14 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1400 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1400 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1400 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1400 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1400 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1400 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar
#43295 [Opn]: php-cgi crash
ID: 43295 Updated by: [EMAIL PROTECTED] Reported By: pioklo at serveradmin dot pl Status: Open Bug Type: CGI related Operating System: Debian 4.0 kernel 2.6.23.1 PHP Version: 5.2.5 New Comment: I can confirm the last additions to this bug. I am also on FreeBSD/AMD64, and today I started getting "zend_mm_heap corrupted" messages. Also, PHP started to sig11 and what I did so far was disable all modules that I do not need - doing this I got rid off some of the obvious crashes. This is my extension.ini http://pastie.caboo.se/private/ytqpr1hnn0slvjsvabt70g php -m: http://pastie.caboo.se/private/yscuxwtkvromili7m15w What can we do to provide more feedback? Previous Comments: [2007-11-25 02:53:11] dns dot bind9 at gmail dot com now,more error msg " [EMAIL PROTECTED] ~#zend_mm_heap corrupted zend_mm_heap corrupted zend_mm_heap corrupted zend_mm_heap corrupted zend_mm_heap corrupted zend_mm_heap corrupted zend_mm_heap corrupted zend_mm_heap corrupted" display on my console! [2007-11-23 18:53:13] f dot fenix at gmail dot com Additional backtrace for previous comment: (gdb) bt #0 0x00537d09 in zend_mm_check_ptr (heap=0x7bf000, ptr=0xb29818, silent=1, __zend_filename=0x6445d8 "/usr/ports/lang/php5/work/php-5.2.5/main/SAPI.c", __zend_lineno=445, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/ports/lang/php5/work/php-5.2.5/Zend/zend_alloc.c:1276 #1 0x00539451 in _zend_mm_free_int (heap=0x7bf000, p=0xb29818, __zend_filename=0x6445d8 "/usr/ports/lang/php5/work/php-5.2.5/main/SAPI.c", __zend_lineno=445, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/ports/lang/php5/work/php-5.2.5/Zend/zend_alloc.c:1909 #2 0x0053a64c in _efree (ptr=0xb29818, __zend_filename=0x6445d8 "/usr/ports/lang/php5/work/php-5.2.5/main/SAPI.c", __zend_lineno=445, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/ports/lang/php5/work/php-5.2.5/Zend/zend_alloc.c:2277 #3 0x0050b99e in sapi_deactivate () at /usr/ports/lang/php5/work/php-5.2.5/main/SAPI.c:445 #4 0x00502397 in php_request_shutdown (dummy=0x0) at /usr/ports/lang/php5/work/php-5.2.5/main/main.c:1494 #5 0x005d8771 in main (argc=3, argv=0x7fffea98) at /usr/ports/lang/php5/work/php-5.2.5/sapi/cgi/cgi_main.c:1972 PS System is AMD64 [2007-11-21 16:41:06] f dot fenix at gmail dot com I also have such bug appeared after update to PHP 5.2.5. System Info: FreeBSD 6.2-RELEASE-p3, nginx/0.5.32, PHP 5.2.5 # php -m [PHP Modules] bcmath bz2 ctype curl date dom gd gettext hash iconv libxml mbstring mhash mysql pcre PDO pgsql posix readline Reflection session SimpleXML sockets SPL SQLite standard tokenizer xml xmlreader xmlwriter zlib [Zend Modules] #gdb /usr/local/bin/php-cgi php-cgi.core --SKIPED-- (gdb) bt #0 0x004e79cf in _zend_mm_free_int () #1 0x004c858a in sapi_deactivate () #2 0x004c1eea in php_request_shutdown () #3 0x00591943 in main () It crashes with such baktrace on ANY script. [2007-11-20 10:45:19] dns dot bind9 at gmail dot com hi,I have same problem on my update php to 5.2.5. My System is FreeBSD 6.1 + Lighttpd 1.4.18 + php5.2.5 + php-cgi. [EMAIL PROTECTED] ~#/usr/local/bin/php-cgi -m [PHP Modules] cgi-fcgi date gd iconv libxml mbstring memcache mysql pcre Reflection session standard xml zlib [Zend Modules] In Lighttpd Logs: 2007-11-20 18:25:24: (mod_fastcgi.c.2462) unexpected end-of-file (perhaps the fastcgi process died): pid: 4823 socket: unix:/tmp/php-fastcgi.socket-0 2007-11-20 18:25:24: (mod_fastcgi.c.3269) response already sent out, but backend returned error on socket: unix:/tmp/php-fastcgi.socket-0 for /detail.php , terminating connection [2007-11-19 13:57:42] pioklo at serveradmin dot pl The diff is here : http://tapsy.pl/phpdiff.txt Content-Type text/html The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/43295 -- Edit this bug report at http://bugs.php.net/?id=43295&edit=1
#43452 [Csd->Opn]: strtotime returns wrong date when requested day is same as first day of the mon
ID: 43452 Updated by: [EMAIL PROTECTED] Reported By: sean dot thorne at gmail dot com -Status: Closed +Status: Open Bug Type: Date/time related Operating System: Mac OS X 10.4.11 PHP Version: 5.2CVS-2007-11-29 (CVS) Assigned To: derick New Comment: Sorry to re-open, I found the same bug on: PHP Version 5.2.6-pl6-gentoo Some code to reproduce: Shows 2008-12-08, while indeed the first Monday in December is 2008-12-01. Previous Comments: [2008-07-23 18:50:15] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2008-07-17 10:32:00] [EMAIL PROTECTED] Yeah, and I've done some work on that -- but it's not ready yet. [2008-07-17 10:29:15] m dot ford at leedsmet dot ac dot uk Then there's a doc problem, because currently http://php.net/strtotime describes its first argument as "The string to parse, according to the GNU » Date Input Formats syntax", with a link to the GNU documentation. If strtotime() does not, in fact, implement the entirety of what's described there, exactly as described, then what's actually implemented should be incorporated into the PHP manual and that link removed. [2008-07-15 17:23:37] [EMAIL PROTECTED] Assigning this to myself, but be aware that we do not necessarily implement this GNU date stuff -- we've never done this either. I'll check it though. [2008-07-15 17:19:38] m dot ford at leedsmet dot ac dot uk Derick, please take another look at this. I've examined it in some depth, and tend to agree there's a bug here. However, if you read the GNU Date Input Formats syntax, linked from http://php.net/manual/function.strtotime.php, very closely, you find it says: "a day of the week will forward the date (only if necessary) to reach that day of the week in the future" ... and ... "a number may precede a day of the week item to move forward supplementary weeks." The crucial word here is "supplementary". Taken together, these specifications suggest that, somewhat counter-intuitively: Monday month year should represent the first Monday of the month, no matter what date it falls on, and 1 Monday month year should be the Monday *after* that (i.e. the 2nd Monday!!), and so on. Other wording in the GNU Date "Day of week items" section would tend to confirm this interpretation. I therefore submit that the bug actually manifests when the first occurrence of the requested weekday falls on any date *other* than the first of the month! :( However you interpret it, it's nonetheless clear that the relationship of "1 weekday" to "weekday" should be fixed -- either according to the GNU specification to occur 1 week later, or more intuitively to mean the same thing. It's definitely NOT right that "1 Monday" (for example) means something different from "Monday" *only* when "Monday" is the 1st of the month...!! The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/43452 -- Edit this bug report at http://bugs.php.net/?id=43452&edit=1
#43452 [Opn]: strtotime returns wrong date when requested day is same as first day of the mon
ID: 43452 Updated by: [EMAIL PROTECTED] Reported By: sean dot thorne at gmail dot com Status: Open Bug Type: Date/time related Operating System: Mac OS X 10.4.11 PHP Version: 5.2CVS-2007-11-29 (CVS) Assigned To: derick New Comment: I had second thoughts about the "timestamp" passed into strtotime(), so I tried to create the date in a slightly different way but it failed never the less. I can also confirm this on 5.2.6_2 on FreeBSD. Additional code: Works: Does not: Previous Comments: [2008-10-16 16:29:22] [EMAIL PROTECTED] Sorry to re-open, I found the same bug on: PHP Version 5.2.6-pl6-gentoo Some code to reproduce: Shows 2008-12-08, while indeed the first Monday in December is 2008-12-01. [2008-07-23 18:50:15] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2008-07-17 10:32:00] [EMAIL PROTECTED] Yeah, and I've done some work on that -- but it's not ready yet. [2008-07-17 10:29:15] m dot ford at leedsmet dot ac dot uk Then there's a doc problem, because currently http://php.net/strtotime describes its first argument as "The string to parse, according to the GNU » Date Input Formats syntax", with a link to the GNU documentation. If strtotime() does not, in fact, implement the entirety of what's described there, exactly as described, then what's actually implemented should be incorporated into the PHP manual and that link removed. [2008-07-15 17:23:37] [EMAIL PROTECTED] Assigning this to myself, but be aware that we do not necessarily implement this GNU date stuff -- we've never done this either. I'll check it though. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/43452 -- Edit this bug report at http://bugs.php.net/?id=43452&edit=1
#43452 [Opn]: strtotime returns wrong date when requested day is same as first day of the mon
ID: 43452 Updated by: [EMAIL PROTECTED] Reported By: sean dot thorne at gmail dot com Status: Open Bug Type: Date/time related Operating System: Mac OS X 10.4.11 PHP Version: 5.2CVS-2007-11-29 (CVS) Assigned To: derick New Comment: Confirmed it broken in 5.2.7-dev as well. Since it appears to be fixed in 5.3-alpha3-dev, is there any chance this fix can be backported? Previous Comments: [2008-10-16 22:56:28] [EMAIL PROTECTED] I had second thoughts about the "timestamp" passed into strtotime(), so I tried to create the date in a slightly different way but it failed never the less. I can also confirm this on 5.2.6_2 on FreeBSD. Additional code: Works: Does not: [2008-10-16 16:29:22] [EMAIL PROTECTED] Sorry to re-open, I found the same bug on: PHP Version 5.2.6-pl6-gentoo Some code to reproduce: Shows 2008-12-08, while indeed the first Monday in December is 2008-12-01. [2008-07-23 18:50:15] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2008-07-17 10:32:00] [EMAIL PROTECTED] Yeah, and I've done some work on that -- but it's not ready yet. [2008-07-17 10:29:15] m dot ford at leedsmet dot ac dot uk Then there's a doc problem, because currently http://php.net/strtotime describes its first argument as "The string to parse, according to the GNU » Date Input Formats syntax", with a link to the GNU documentation. If strtotime() does not, in fact, implement the entirety of what's described there, exactly as described, then what's actually implemented should be incorporated into the PHP manual and that link removed. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/43452 -- Edit this bug report at http://bugs.php.net/?id=43452&edit=1
#45989 [Bgs->Opn]: json_decode() passes through certain invalid JSON strings
ID: 45989
Updated by: [EMAIL PROTECTED]
Reported By: steven at acko dot net
-Status: Bogus
+Status: Open
Bug Type: JSON related
Operating System: Mac OS X
PHP Version: 5.2.6
New Comment:
@Iliaa:
Could this bug be re-evaluated or a more detailed explaination as of
why the docs sometimes note that "NULL" is returned on invalid json, and
why sometimes json_decode() returns the string instead?
If the function returns "whatever" then the docs should be updated to
tell the user to not rely on what is returned by json_decode at all.
;-)
I double-checked some of Steve's examples on jsonlint.com (which is in
most docs cited as the reference validator for json data) and they all
show up as "invalid".
I also build the most recent 5.2.7 snapshot:
./configure --disable-all --enable-json
[EMAIL PROTECTED]:~/php5.2-200811171330$ ./sapi/cli/php test-45989.php
string(14) "'invalid json'"
string(12) "invalid json"
string(2) " {"
string(2) " ["
[EMAIL PROTECTED]:~/php5.2-200811171330$ ./sapi/cli/php --ini
Configuration File (php.ini) Path: /usr/local/lib
Loaded Configuration File: (none)
Scan for additional .ini files in: (none)
Additional .ini files parsed: (none)
[EMAIL PROTECTED]:~/php5.2-200811171330$ ./sapi/cli/php -m
[PHP Modules]
date
json
Reflection
standard
[Zend Modules]
I'm gonna write a test and send it to QA too.
Previous Comments:
[2008-09-10 01:14:23] steven at acko dot net
Please clarify the bogus classification.
The following each returns NULL, as expected:
var_dump(json_decode('[')); // unmatched bracket
var_dump(json_decode('{')); // unmatched brace
var_dump(json_decode('{}}')); // unmatched brace
var_dump(json_decode('{error error}')); // invalid object key/value
notation
var_dump(json_decode('["\"]')); // unclosed string
var_dump(json_decode('[" \x "]')); // invalid escape code
Yet the following each returns the literal argument as a string:
var_dump(json_decode(' ['));
var_dump(json_decode(' {'));
var_dump(json_decode(' {}}'));
var_dump(json_decode(' {error error}'));
var_dump(json_decode('"\"'));
var_dump(json_decode('" \x "'));
Please examine the examples closely: they are all meaningless, invalid
JSON. Even under the
most widely stretched definition of JSON, the above is not JSON encoded
data. Yet
json_decode() arbitarily returns /some of it/ as a string... and in a
way that looks
suspiciously like a bad parser implementation.
If this was merely a case of json_decode() returning /all/ invalid json
as is, then it could
be classified as an implementation quirk. But because of how
inconsistent it is now, you
can't say that it is by design or following any kind of spec.
E.g. how would you currently see if json_decode() succeeded or not?
[2008-09-10 00:38:09] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
.
[2008-09-04 00:32:20] steven at acko dot net
Description:
When json_decode() is given certain invalid JSON strings, it will
return
the literal string as the result, rather than returning NULL.
Note: in #38680, the decision was made to allow json_decode() to accept
literal basic types (strings, ints, ...) even though this is not
allowed
by RFC 4627 (which only allows objects/arrays). This bug report is
different because even under the PHP interpretation of JSON, these
strings can not be considered valid, and trivial variations on them do
in fact throw an error as expected.
(The non-standard behaviour introduced in #38680 is not documented at
all by the way, which is kind of ironic given the numerous issues that
have 'go read the spec' as the answer)
Reproduce code:
---
var_dump(json_decode("'invalid json'"));
var_dump(json_decode('invalid json'));
var_dump(json_decode(' {'));
var_dump(json_decode(' ['));
Expected result:
NULL
NULL
NULL
NULL
Actual result:
--
string(14) "'invalid json'"
string(12) "invalid json"
string(2) " {"
string(2) " ["
--
Edit this bug report at http://bugs.php.net/?id=45989&edit=1
#45989 [Opn]: json_decode() passes through certain invalid JSON strings
ID: 45989
Updated by: [EMAIL PROTECTED]
Reported By: steven at acko dot net
Status: Open
Bug Type: JSON related
Operating System: Mac OS X
PHP Version: 5.2.6
New Comment:
Just to add to this:
I know that the function is not supposed to be a JSON validator, but
it's supposed to return the string as is -- in case it's a literal type,
but why does it in some cases return "null" then?
For example:
$bad_json = "{ 'bar': 'baz' }";
json_decode($bad_json); // null
I know this is "probably" an edge-case but $bad_json could be my own
/valid/ string -- not valid JSON. Because a string could look like
anything. Point well taken, I'm passing in a pretty /funky/ looking
string. But instead of "NULL", json_decode should return the string
as-is.
That is, according to the documentation, a bug. ;-)
Lots of people also seemed to rely on json_decode as a json validator.
Which is -- once you understand the subtle differences -- not the case.
The case should be made for either one though.
Previous Comments:
[2008-11-17 15:23:35] [EMAIL PROTECTED]
@Iliaa:
Could this bug be re-evaluated or a more detailed explaination as of
why the docs sometimes note that "NULL" is returned on invalid json, and
why sometimes json_decode() returns the string instead?
If the function returns "whatever" then the docs should be updated to
tell the user to not rely on what is returned by json_decode at all.
;-)
I double-checked some of Steve's examples on jsonlint.com (which is in
most docs cited as the reference validator for json data) and they all
show up as "invalid".
I also build the most recent 5.2.7 snapshot:
./configure --disable-all --enable-json
[EMAIL PROTECTED]:~/php5.2-200811171330$ ./sapi/cli/php test-45989.php
string(14) "'invalid json'"
string(12) "invalid json"
string(2) " {"
string(2) " ["
[EMAIL PROTECTED]:~/php5.2-200811171330$ ./sapi/cli/php --ini
Configuration File (php.ini) Path: /usr/local/lib
Loaded Configuration File: (none)
Scan for additional .ini files in: (none)
Additional .ini files parsed: (none)
[EMAIL PROTECTED]:~/php5.2-200811171330$ ./sapi/cli/php -m
[PHP Modules]
date
json
Reflection
standard
[Zend Modules]
I'm gonna write a test and send it to QA too.
[2008-09-10 01:14:23] steven at acko dot net
Please clarify the bogus classification.
The following each returns NULL, as expected:
var_dump(json_decode('[')); // unmatched bracket
var_dump(json_decode('{')); // unmatched brace
var_dump(json_decode('{}}')); // unmatched brace
var_dump(json_decode('{error error}')); // invalid object key/value
notation
var_dump(json_decode('["\"]')); // unclosed string
var_dump(json_decode('[" \x "]')); // invalid escape code
Yet the following each returns the literal argument as a string:
var_dump(json_decode(' ['));
var_dump(json_decode(' {'));
var_dump(json_decode(' {}}'));
var_dump(json_decode(' {error error}'));
var_dump(json_decode('"\"'));
var_dump(json_decode('" \x "'));
Please examine the examples closely: they are all meaningless, invalid
JSON. Even under the
most widely stretched definition of JSON, the above is not JSON encoded
data. Yet
json_decode() arbitarily returns /some of it/ as a string... and in a
way that looks
suspiciously like a bad parser implementation.
If this was merely a case of json_decode() returning /all/ invalid json
as is, then it could
be classified as an implementation quirk. But because of how
inconsistent it is now, you
can't say that it is by design or following any kind of spec.
E.g. how would you currently see if json_decode() succeeded or not?
[2008-09-10 00:38:09] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
.
[2008-09-04 00:32:20] steven at acko dot net
Description:
When json_decode() is given certain invalid JSON strings, it will
return
the literal string as the result, rather than returning NULL.
Note: in #38680, the decision was made to allow json_decode() to accept
literal basic types (strings, ints, ...) even though this is not
allowed
by RFC 4627 (which only allows objects/arrays). This bug report is
different because even under the PHP interpretation of JSON, these
strings can not be considered valid, and trivial variations on them do
in fact throw an error as expected.
(The non-standard behaviour introduced in #38680 is not documented at
all by the way, which is kind of ironic given the numerous issues that
have 'go
#47937 [Fbk]: headers_sent() reports 'true' after system() call in ob_start()
ID: 47937 Updated by: t...@php.net Reported By: t...@php.net Status: Feedback Bug Type: Output Control Operating System: FreeBSD, MacOSX PHP Version: 5.2.9 New Comment: On FreeBSD with 5.2.9 the SAPI is apache2handler The MacOSX 5.2.9 and 5.3.0RC1 is cli. Do you still need me to try this on Linux? If so, I could compile 5.2.9 and 5.3.0RC1 on Ubuntu tomorrow. Previous Comments: [2009-04-13 18:04:20] j...@php.net Interesting: # php-cgi -n t.php X-Powered-By: PHP/5.2.9 Content-type: text/html bool(false) string(0) "" int(0) # php-cgi -q -n t.php bool(true) string(0) "" int(0) What SAPI are you using..? [2009-04-13 18:01:45] j...@php.net I can not reproduce this with Linux. Please try without the Suhosin patch. [2009-04-09 13:55:04] t...@php.net Description: This is the php -v from one of the servers: PHP 5.2.9 with Suhosin-Patch 0.9.7 (cli) (built: Apr 9 2009 03:31:34) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies This is another one (macosx): PHP 5.2.9 (cli) (built: Apr 2 2009 16:07:08) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies with Xdebug v2.0.4, Copyright (c) 2002-2008, by Derick Rethans Right after my system() call, headers were send. This works differently in 5.2.6 and 5.2.8. I've scanned through UPDATING/CHANGELOG but couldn't find anything. I've disabled APC to make sure it's not connected. php -m: [PHP Modules] ctype date dom filter iconv libxml mbstring mcrypt mysqli pcre Reflection session SimpleXML sockets SPL standard tidy xml zlib Also reproduced with RC1 on 5.3: PHP 5.3.0RC1 (cli) (built: Apr 9 2009 15:45:09) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies Reproduce code: --- http://bugs.php.net/?id=47937&edit=1
#47937 [Csd]: headers_sent() reports 'true' after system() call in ob_start()
ID: 47937 Updated by: t...@php.net Reported By: t...@php.net Status: Closed Bug Type:Output Control PHP Version: 5.2.9 New Comment: Thanks, everyone. :) Previous Comments: [2009-04-19 15:01:51] il...@php.net This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. FYI Jani: -q for cgi sets headers_sent setting to 1 right a way, hence the different result. [2009-04-15 11:31:32] lbarn...@php.net Verified, system() calls sapi_flush() [2009-04-13 22:25:17] t...@php.net On FreeBSD with 5.2.9 the SAPI is apache2handler The MacOSX 5.2.9 and 5.3.0RC1 is cli. Do you still need me to try this on Linux? If so, I could compile 5.2.9 and 5.3.0RC1 on Ubuntu tomorrow. [2009-04-13 18:04:20] j...@php.net Interesting: # php-cgi -n t.php X-Powered-By: PHP/5.2.9 Content-type: text/html bool(false) string(0) "" int(0) # php-cgi -q -n t.php bool(true) string(0) "" int(0) What SAPI are you using..? [2009-04-13 18:01:45] j...@php.net I can not reproduce this with Linux. Please try without the Suhosin patch. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/47937 -- Edit this bug report at http://bugs.php.net/?id=47937&edit=1
Bug #53328 [Opn]: stream_flush error does not cause copy to return false
Edit report at http://bugs.php.net/bug.php?id=53328&edit=1 ID: 53328 Updated by: t...@php.net Reported by:mike at silverorange dot com Summary:stream_flush error does not cause copy to return false Status: Open Type: Bug Package:Streams related Operating System: Linux PHP Version:5.2.14 Block user comment: N Private report: N New Comment: Hey Mike, I wanted to write a test case but I fail to reproduce this on 5.3.2 so far. E.g., I wrapped your code into a phpt, all I get is: Warning: copy(): The second argument to copy() function cannot be a directory in /home/till/test/bug53328.php on line 60 bool(false) [ On a sidenote, I don't get this error message either. 'foo' is not a directory, but maybe this means that we have to implement more in the example wrapper for it to work, or this is another bug in the streamwrapper?] Anyway, aside from the weird error message it seems to work indeed on 5.3.2. Here is your code wrapped in a phpt: http://friendpaste.com/7Id22SbWNEBnwLhi9FnSTu Execute with: pear run-tests bug53328.phpt Previous Comments: [2010-11-17 06:48:23] mike at silverorange dot com Description: In a custom stream wrapper if stream_flush() returns false as the documentation says it may, parent copy operations do not return false. Test script: --- http://labs.silverorange.com/files/php-stream-wrapper/test.phps http://labs.silverorange.com/files/php-stream-wrapper/test.txt Expected result: copy should return false. Actual result: -- copy returns true. -- Edit this bug report at http://bugs.php.net/bug.php?id=53328&edit=1
Bug #55196 [Bgs]: PEAR doesn't honor the ext_dir configuration variable
Edit report at https://bugs.php.net/bug.php?id=55196&edit=1 ID: 55196 Updated by: t...@php.net Reported by:kalessin at kalessin dot fr Summary:PEAR doesn't honor the ext_dir configuration variable Status: Bogus Type: Bug Package:Unknown/Other Function Operating System: Irrelevant PHP Version:Irrelevant Block user comment: N Private report: N New Comment: It's bogus anyway. It's not supposed to suggest that. You'll have to set extension_dir in your php.ini so an extension is found and can be loaded. The complete path is never added to extension=foo.so. Previous Comments: [2011-07-13 02:21:42] paj...@php.net Please report this bug here: http://pear.php.net/pear [2011-07-12 22:55:05] kalessin at kalessin dot fr Description: I'm using PEAR 1.9.0, but newer version are also affected. PEAR doesn't honor the ext_dir configuration variable, or I didn't understand how to use it. The ext_dir configuration variable is supposed to be used when you want to install extensions in a custom directory. This is useful to allow unprivileged user to install php extensions in their home directories. To make the ext_dir configuration variable working I fixed the build function in Builder.php to use ext_dir as a prefix for the destination path of the extension. I also fixed the enableExtension function in Command/Install.php to write the full path to the extension in php.ini when ext_dir is set. While these fixes fit my use case they are not perfect because they use ext_dir as a prefix instead as the full dirname for the extension. Moreover I didn't take care of possible regressions and some other places in the code certainly need to be adjusted (e.g: error messages). The attached patch applies to SVN r313186 Best regards PS: It's not clear where this bug should be reported, the PEAR website doesn't seem to have the concept of bugs in PEAR itself but only in packages⦠Test script: --- #!/bin/sh ext_dir=`mktemp -d` pear config-set ext_dir $ext_dir user pecl install mongo rm -rf $ext_dir Expected result: [...] Build process completed successfully Installing '/tmp/tmp.km7ZJACEQ3/lib/php5/20090626/mongo.so' install ok: channel://pecl.php.net/mongo-1.2.1 configuration option "php_ini" is not set to php.ini location You should add "extension=/tmp/tmp.km7ZJACEQ3/lib/php5/20090626/mongo.so" to php.ini % Actual result: -- [...] Build process completed successfully Installing '/usr/lib/php5/20090626/mongo.so' install ok: channel://pecl.php.net/mongo-1.2.1 configuration option "php_ini" is not set to php.ini location You should add "extension=mongo.so" to php.ini % -- Edit this bug report at https://bugs.php.net/bug.php?id=55196&edit=1
Bug #55194 [Opn->Bgs]: PEAR doesn't honor the ext_dir configuration variable
Edit report at https://bugs.php.net/bug.php?id=55194&edit=1 ID: 55194 Updated by: t...@php.net Reported by:kalessin at kalessin dot fr -Summary:PEAR doesn't work with empty php.ini files +Summary:PEAR doesn't honor the ext_dir configuration variable -Status: Open +Status: Bogus Type: Bug Package:Unknown/Other Function Operating System: Irrelevant PHP Version:Irrelevant Block user comment: N Private report: N New Comment: It's bogus anyway. It's not supposed to suggest that. You'll have to set extension_dir in your php.ini so an extension is found and can be loaded. The complete path is never added to extension=foo.so. Previous Comments: [2011-07-12 22:21:23] kalessin at kalessin dot fr Description: I'm using PEAR 1.9.0, but newer version are also affected. PEAR fails to open and parse an empty php.ini file because the return value of file() is not checked correctly (see attached patch). It's easy to end up with an empty php.ini file when you set the php_ini configuration variable to a custom location. The attached patch applies to SVN r313186 Best regards PS: It's not clear where this bug should be reported, the PEAR website doesn't seem to have the concept of bugs in PEAR itself but only in packages⦠Test script: --- #!/bin/sh php_ini=`mktemp` pear config-set php_ini $php_ini user pecl install mongo rm -f $php_ini Expected result: [..] install ok: channel://pecl.php.net/mongo-1.2.1 Extension mongo enabled in php.ini % Actual result: -- [...] install ok: channel://pecl.php.net/mongo-1.2.1 php.ini "/tmp/tmp.V6wU8jpMA4" could not be read You should add "extension=mongo.so" to php.ini % -- Edit this bug report at https://bugs.php.net/bug.php?id=55194&edit=1
#22425 [Com]: session_start() causes apache segfault/crash
ID: 22425 Comment by: till at klimpong dot com Reported By: addinitz at hotmail dot com Status: No Feedback Bug Type: Session related Operating System: Gentoo Linux PHP Version: 4.3.1 New Comment: I have the same problem in PHP 4.3.11 and FreeBSD 4.10. Previous Comments: [2003-03-25 22:24:46] [EMAIL PROTECTED] sounds like some optimization problem in the compiler. [2003-03-25 20:42:29] juvenal dot jr at uol dot com dot br I'm having the same problem here (PHP 4.3.1) but with RH 7.3 with the latest packages from RHN (apache-1.3.27-2, glibc-2.2.5-43), and a kernel with SGI XFS patches applied (kernel-2.4.18-4SGI_XFS_1.1). When compiled with --disable-debug, I got the Segmentation fault problem with session_start(), but when I use --enable-debug on compile, the SEGV vanishes. I'd like to ask if there is another way to get important info to fix it (I cannot use the --enable-debug version because I need Zend Optimizer and Zend Debugger, and they only work with the --disable-debug version of PHP). I'm waiting your answer. Cheers, Juvenal A. Silva Jr. [2003-03-09 19:14:24] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-02-26 00:58:37] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2003-02-26 00:11:34] addinitz at hotmail dot com version 4.2.3 works fine when I call the session_start function, but in both 4.3.0 and 4.3.1, session_start() causes an immediate crash. The OS is Gentoo Linux 1.4_rc2. Apache 2.0.44. -- Edit this bug report at http://bugs.php.net/?id=22425&edit=1
#22425 [Com]: session_start() causes apache segfault/crash
ID: 22425 Comment by: till at klimpong dot com Reported By: addinitz at hotmail dot com Status: No Feedback Bug Type: Session related Operating System: Gentoo Linux PHP Version: 4.3.1 New Comment: Ok, here is my fix. *Although* I had installed everything from scratch, I just went into the /usr/ports/www/php4-session directory, and issued "make deinstall". Then restarted Apache to reflect changes - worked. Then I did, "make clean && make install", and reinstalled the session extension again. Restarted Apache, and the segfaults are gone. Hope this helps! Till Previous Comments: [2005-06-05 19:29:24] till at klimpong dot com I have the same problem in PHP 4.3.11 and FreeBSD 4.10. [2003-03-25 22:24:46] [EMAIL PROTECTED] sounds like some optimization problem in the compiler. [2003-03-25 20:42:29] juvenal dot jr at uol dot com dot br I'm having the same problem here (PHP 4.3.1) but with RH 7.3 with the latest packages from RHN (apache-1.3.27-2, glibc-2.2.5-43), and a kernel with SGI XFS patches applied (kernel-2.4.18-4SGI_XFS_1.1). When compiled with --disable-debug, I got the Segmentation fault problem with session_start(), but when I use --enable-debug on compile, the SEGV vanishes. I'd like to ask if there is another way to get important info to fix it (I cannot use the --enable-debug version because I need Zend Optimizer and Zend Debugger, and they only work with the --disable-debug version of PHP). I'm waiting your answer. Cheers, Juvenal A. Silva Jr. [2003-03-09 19:14:24] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-02-26 00:58:37] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/22425 -- Edit this bug report at http://bugs.php.net/?id=22425&edit=1
#33362 [NEW]: ftp_mdtm does not return correct date
From: till at klimpong dot com Operating system: FreeBSD 5.2-current PHP version: 4.3.10 PHP Bug Type: Unknown/Other Function Bug description: ftp_mdtm does not return correct date Description: ftp_mdtm always returns a wrong unix timestamp. Our FTPd is proftpd (with TimesGMT off). The date, time and timezone are set correctly on the server. When I connect to the FTP with another client (such as filezilla), all dates are displayed correct. This error only occurs within a PHP script. For example: current time on the server: 2:24PM current time returned by ftp_mdtm: 4:24 PM This example works: Displays the correct time, so I guess this problem comes from ftp_mtdm(). Reproduce code: --- Expected result: File's modification time. Actual result: -- The file's modification time plus two hours. -- Edit bug report at http://bugs.php.net/?id=33362&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33362&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33362&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33362&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33362&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33362&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33362&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33362&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33362&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33362&r=support Expected behavior: http://bugs.php.net/fix.php?id=33362&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33362&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33362&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33362&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33362&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33362&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33362&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33362&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33362&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33362&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33362&r=mysqlcfg
#33362 [Opn]: ftp_mdtm does not return correct date
ID: 33362 User updated by: till at klimpong dot com Reported By: till at klimpong dot com Status: Open Bug Type: Unknown/Other Function Operating System: FreeBSD 5.2-current PHP Version: 4.3.10 New Comment: Forgot to add. I also set the locale on my system. Just to make sure that this is not some weird conversion bug. Previous Comments: [2005-06-16 14:39:42] till at klimpong dot com Description: ftp_mdtm always returns a wrong unix timestamp. Our FTPd is proftpd (with TimesGMT off). The date, time and timezone are set correctly on the server. When I connect to the FTP with another client (such as filezilla), all dates are displayed correct. This error only occurs within a PHP script. For example: current time on the server: 2:24PM current time returned by ftp_mdtm: 4:24 PM This example works: Displays the correct time, so I guess this problem comes from ftp_mtdm(). Reproduce code: --- Expected result: File's modification time. Actual result: -- The file's modification time plus two hours. -- Edit this bug report at http://bugs.php.net/?id=33362&edit=1
#33362 [Bgs->Opn]: ftp_mdtm does not return correct date
ID: 33362 User updated by: till at klimpong dot com Reported By: till at klimpong dot com -Status: Bogus +Status: Open Bug Type: FTP related Operating System: FreeBSD 5.2-current PHP Version: 4.3.10 New Comment: Well, the server's time is set to GMT+2 already. The server is in my timezone and so on. So my local time and the server's time are the same. If the server is GMT+2, then the function returns it with GMT+4. Where does the difference come from then? Previous Comments: [2005-06-16 18:10:53] [EMAIL PROTECTED] Yes, because your time is GMT+2. [2005-06-16 14:42:04] till at klimpong dot com Forgot to add. I also set the locale on my system. Just to make sure that this is not some weird conversion bug. [2005-06-16 14:39:42] till at klimpong dot com Description: ftp_mdtm always returns a wrong unix timestamp. Our FTPd is proftpd (with TimesGMT off). The date, time and timezone are set correctly on the server. When I connect to the FTP with another client (such as filezilla), all dates are displayed correct. This error only occurs within a PHP script. For example: current time on the server: 2:24PM current time returned by ftp_mdtm: 4:24 PM This example works: Displays the correct time, so I guess this problem comes from ftp_mtdm(). Reproduce code: --- Expected result: File's modification time. Actual result: -- The file's modification time plus two hours. -- Edit this bug report at http://bugs.php.net/?id=33362&edit=1
#33362 [Fbk->Opn]: ftp_mdtm does not return correct date
ID: 33362 User updated by: till at klimpong dot com Reported By: till at klimpong dot com -Status: Feedback +Status: Open Bug Type: FTP related Operating System: FreeBSD 5.2-current PHP Version: 4.3.10 New Comment: Command: MDTM apache-ssl.txt Response: 213 20050616141816 Which is correct. ftp_mdtm on the same file returns 11189314961 Previous Comments: [2005-06-16 18:29:22] [EMAIL PROTECTED] Check what MDTM command gives you for that file in question using your ftp client: > debug > modtime yourfile [2005-06-16 18:19:40] till at klimpong dot com Well, the server's time is set to GMT+2 already. The server is in my timezone and so on. So my local time and the server's time are the same. If the server is GMT+2, then the function returns it with GMT+4. Where does the difference come from then? [2005-06-16 18:10:53] [EMAIL PROTECTED] Yes, because your time is GMT+2. [2005-06-16 14:42:04] till at klimpong dot com Forgot to add. I also set the locale on my system. Just to make sure that this is not some weird conversion bug. [2005-06-16 14:39:42] till at klimpong dot com Description: ftp_mdtm always returns a wrong unix timestamp. Our FTPd is proftpd (with TimesGMT off). The date, time and timezone are set correctly on the server. When I connect to the FTP with another client (such as filezilla), all dates are displayed correct. This error only occurs within a PHP script. For example: current time on the server: 2:24PM current time returned by ftp_mdtm: 4:24 PM This example works: Displays the correct time, so I guess this problem comes from ftp_mtdm(). Reproduce code: --- Expected result: File's modification time. Actual result: -- The file's modification time plus two hours. -- Edit this bug report at http://bugs.php.net/?id=33362&edit=1
#33362 [Fbk->Opn]: ftp_mdtm does not return correct date
ID: 33362
User updated by: till at klimpong dot com
Reported By: till at klimpong dot com
-Status: Feedback
+Status: Open
Bug Type: FTP related
Operating System: FreeBSD 5.2-current
PHP Version: 4.3.10
New Comment:
Typo indeed.
So I substituted strftime with gmdate and it works.
Thanks for your help.
Previous Comments:
[2005-06-16 18:55:26] [EMAIL PROTECTED]
You have extra '1' in the timestamp. (typo, I hope :)
# php -r 'echo gmdate("F d Y H:i:s", 1118931496);'
June 16 2005 14:18:16
That looks pretty okay to me.
----
[2005-06-16 18:46:22] till at klimpong dot com
Command: MDTM apache-ssl.txt
Response: 213 20050616141816
Which is correct.
ftp_mdtm on the same file returns 11189314961
[2005-06-16 18:29:22] [EMAIL PROTECTED]
Check what MDTM command gives you for that file in question
using your ftp client:
> debug
> modtime yourfile
[2005-06-16 18:19:40] till at klimpong dot com
Well, the server's time is set to GMT+2 already. The server is in my
timezone and so on. So my local time and the server's time are the
same.
If the server is GMT+2, then the function returns it with GMT+4. Where
does the difference come from then?
[2005-06-16 18:10:53] [EMAIL PROTECTED]
Yes, because your time is GMT+2.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/33362
--
Edit this bug report at http://bugs.php.net/?id=33362&edit=1
#16804 [Com]: failed to configure with mysql-4.01-alpha-ssl
ID: 16804 Comment by: [EMAIL PROTECTED] Reported By: Xuefer at 21cn dot com Status: Bogus Bug Type: MySQL related Operating System: linux-redhat 7.2 PHP Version: 4.2.0 New Comment: I am having the same Problem. My ./configure line: ./configure --with-apxs=/usr/local/sbin/apxs --with-config-file-path=/usr/local/etc --enable-versioning --with-regex=system --without-gd --with-pgsql --with-gd=/usr/local --enable-gd-native-ttf --with-freetype-dir=/usr/local --with-jpeg-dir=/usr/local --with-png-dir=/usr/local --with-zlib --with-bz2=/usr --with-mcrypt=/usr/local --with-mhash=/usr/local --with-pdflib=/usr/local --with-zlib-dir=/usr --with-jpeg-dir=/usr/local --with-png-dir=/usr/local --with-tiff-dir=/usr/local --with-mysql=/usr/local/mysql4 --with-openssl --with-expat-dir=/usr/local --with-xmlrpc --enable-xslt --with-xslt-sablot --enable-wddx --with-dom=/usr/local --enable-ftp --with-gettext=/usr/local --enable-mbregex --enable-bcmath --enable-sockets --enable-sysvsem --enable-sysvshm --enable-trans-sid --with-iconv=/usr/local --enable-exif --enable-track-vars --with-imap --with-mcal --with-pear Make fails on: ... lrpc/libxmlrpc/xml_to_soap.lo ext/xslt/xslt.lo ext/xslt/sablot.lo regex/regcomp.lo regex/regexec.lo regex/regerror.lo regex/regfree.lo TSRM/TSRM.lo TSRM/tsrm_strtok_r.lo TSRM/tsrm_virtual_cwd.lo main/main.lo main/snprintf.lo main/spprintf.lo main/php_sprintf.lo main/safe_mode.lo main/fopen_wrappers.lo main/alloca.lo main/php_scandir.lo main/php_ini.lo main/SAPI.lo main/rfc1867.lo main/php_content_types.lo main/strlcpy.lo main/strlcat.lo main/mergesort.lo main/reentrancy.lo main/php_variables.lo main/php_ticks.lo main/streams.lo main/network.lo main/php_open_temporary_file.lo main/php_logos.lo main/output.lo main/memory_streams.lo main/user_streams.lo Zend/zend_language_parser.lo Zend/zend_language_scanner.lo Zend/zend_ini_parser.lo Zend/zend_ini_scanner.lo Zend/zend_alloc.lo Zend/zend_compile.lo Zend/zend_constants.lo Zend/zend_dynamic_array.lo Zend/zend_execute_API.lo Zend/zend_highlight.lo Zend/zend_llist.lo Zend/zend_opcode.lo Zend/zend_operators.lo Zend/zend_ptr_stack.lo Zend/zend_stack.lo Zend/zend_variables.lo Zend/zend.lo Zend/zend_API.lo Zend/zend_extensions.lo Zend/zend_hash.lo Zend/zend_list.lo Zend/zend_indent.lo Zend/zend_builtin_functions.lo Zend/zend_sprintf.lo Zend/zend_ini.lo Zend/zend_qsort.lo Zend/zend_multibyte.lo Zend/zend_execute.lo sapi/cli/php_cli.lo sapi/cli/getopt.lo main/internal_functions_cli.lo -lcrypt -lmcal -lc-client4 -lsablot -lexpat -lexpat -lexpat -lexpat -lcrypt -lpq -lpdf -lz -ltiff -lpng -ljpeg -lmysqlclient -lmhash -lmcrypt -lltdl -lcrypt -lpam -liconv -lintl -lgd -lfreetype -lpng -lz -ljpeg -lz -lbz2 -lz -lssl -lcrypto -lm -lxml2 -lz -lm -lcrypt -lcrypt -o sapi/cli/php ext/openssl/openssl.lo: In function `zm_startup_openssl': /usr/src/php-4.3.3/ext/openssl/openssl.c(.text+0xb69): undefined reference to `OpenSSL_add_all_algorithms' *** Error code 1 My System: x86, FreeBSD, PHP 4.3.3, MySQL 4.0.15 Previous Comments: [2002-07-02 22:51:15] [EMAIL PROTECTED] Not really bug. If you want ssl support with mysql, you need to use --with-openssl [2002-04-25 02:11:15] Xuefer at 21cn dot com i've tested again again ok now mysql# configure --with-openssl=/usr .. this works fine even php without openssl module why do i have to specify DIR ? it this bug is bogus, it should be explain about [DIR] in document [2002-04-25 01:30:06] Xuefer at 21cn dot com php '--with-openssl' still not help no "-lssl" is added for linking but if i configure php '--with-openssl=/usr' passed why? it's said "--with-openssl=[DIR]", DIR should can optional right ? i don't wanna compile openssl functions for php [2002-04-24 20:13:00] [EMAIL PROTECTED] Does adding --with-openssl to your PHP configure line help? [2002-04-24 14:21:06] Xuefer at 21cn dot com mysql# configure --with-openssl .. but now mysql# configure --with-openssl=share it's ok The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/16804 -- Edit this bug report at http://bugs.php.net/?id=16804&edit=1
#27905 [NEW]: make failes on GD function
From: till at klimpong dot com Operating system: freebsd 4.6 PHP version: 4.3.5 PHP Bug Type: Compile Failure Bug description: make failes on GD function Description: configure: ./configure --with-apxs=/usr/local/sbin/apxs --with-config-file-path=/usr/local/etc --enable-versioning --with-regex=system --without-gd --with-pgsql --with-gd=/usr/local --enable-gd-native-ttf --with-freetype-dir=/usr/local --with-jpeg-dir=/usr/local --with-png-dir=/usr/local --with-zlib --with-bz2=/usr --with-mcrypt=/usr/local --with-mhash=/usr/local --with-pdflib=/usr/local --with-zlib-dir=/usr --with-jpeg-dir=/usr/local --with-png-dir=/usr/local --with-tiff-dir=/usr/local --with-mysql=/usr/local/mysql4 --with-expat-dir=/usr/local --with-xmlrpc --enable-xslt --with-xslt-sablot --enable-wddx --with-dom=/usr/local --enable-ftp --with-gettext=/usr/local --enable-mbregex --enable-bcmath --enable-sockets --enable-sysvsem --enable-sysvshm --enable-trans-sid --with-iconv=/usr/local --enable-exif --enable-track-vars --with-imap --with-mcal --with-pear --with-openssl=/usr/local error: include/c-client -I/usr/local/include/mcal -I/usr/local/mysql4/include/mysql -I/usr/local/pgsql/include -I/usr/src/php-4.3.6RC2/TSRM -g -O2 -prefer-pic -c /usr/src/php-4.3.6RC2/ext/ftp/php_ftp.c -o ext/ftp/php_ftp.lo /bin/sh /usr/src/php-4.3.6RC2/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/ftp/ -I/usr/src/php-4.3.6RC2/ext/ftp/ -DPHP_ATOM_INC -I/usr/src/php-4.3.6RC2/include -I/usr/src/php-4.3.6RC2/main -I/usr/src/php-4.3.6RC2 -I/usr/src/php-4.3.6RC2/Zend -I/usr/local/include -I/usr/local/include/libxml2 -I/usr/local/include/freetype2 -I/usr/local/include/gd -I/usr/local/include/c-client -I/usr/local/include/mcal -I/usr/local/mysql4/include/mysql -I/usr/local/pgsql/include -I/usr/src/php-4.3.6RC2/TSRM -g -O2 -prefer-pic -c /usr/src/php-4.3.6RC2/ext/ftp/ftp.c -o ext/ftp/ftp.lo /bin/sh /usr/src/php-4.3.6RC2/libtool --silent --preserve-dup-deps --mode=compile gcc -I/usr/local/include/gd -Iext/gd/ -I/usr/src/php-4.3.6RC2/ext/gd/ -DPHP_ATOM_INC -I/usr/src/php-4.3.6RC2/include -I/usr/src/php-4.3.6RC2/main -I/usr/src/php-4.3.6RC2 -I/usr/src/php-4.3.6RC2/Zend -I/usr/local/include -I/usr/local/include/libxml2 -I/usr/local/include/freetype2 -I/usr/local/include/gd -I/usr/local/include/c-client -I/usr/local/include/mcal -I/usr/local/mysql4/include/mysql -I/usr/local/pgsql/include -I/usr/src/php-4.3.6RC2/TSRM -g -O2 -prefer-pic -c /usr/src/php-4.3.6RC2/ext/gd/gd.c -o ext/gd/gd.lo /usr/src/php-4.3.6RC2/ext/gd/gd.c: In function `_php_image_bw_convert': /usr/src/php-4.3.6RC2/ext/gd/gd.c:3642: structure has no member named `trueColor' *** Error code 1 ./configure runs smooth, make fails. I tried it on 4.3.5 and 4.3.6RC2, both fail. 4.3.4 worked for me. -- Edit bug report at http://bugs.php.net/?id=27905&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27905&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27905&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27905&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27905&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27905&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27905&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27905&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27905&r=support Expected behavior: http://bugs.php.net/fix.php?id=27905&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27905&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27905&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27905&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27905&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27905&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27905&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27905&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27905&r=float
#28675 [NEW]: compiling with internal GD lib fails
From: till at klimpong dot com Operating system: FreeBSD 4.6 PHP version: 4.3.7 PHP Bug Type: Compile Failure Bug description: compiling with internal GD lib fails Description: I'm using 4.3.7 stable. Configure string: ./configure \ --with-apxs=/usr/local/sbin/apxs \ --with-config-file-path=/usr/local/etc \ --enable-versioning \ --with-regex=system \ --with-pgsql \ --with-gd \ --enable-gd-native-ttf \ --with-freetype-dir=/usr/local \ --with-jpeg-dir=/usr/local \ --with-png-dir=/usr/local \ --with-zlib \ --with-bz2=/usr \ --with-mcrypt=/usr/local \ --with-mhash=/usr/local \ --with-pdflib=/usr/local \ --with-zlib-dir=/usr \ --with-jpeg-dir=/usr/local \ --with-png-dir=/usr/local \ --with-tiff-dir=/usr/local \ --with-mysql=/usr/local/mysql4 \ --with-expat-dir=/usr/local \ --with-xmlrpc \ --enable-xslt \ --with-xslt-sablot \ --enable-wddx \ --with-dom=/usr/local \ --enable-ftp \ --with-gettext=/usr/local \ --enable-mbregex \ --enable-bcmath \ --enable-sockets \ --enable-sysvsem \ --enable-sysvshm \ --enable-trans-sid \ --with-iconv=/usr/local \ --enable-exif \ --enable-track-vars \ --with-imap \ --with-mcal \ --with-pear \ --with-openssl=/usr/local \ --disable-ipv6 Make fails with: ext/gd/gd.lo: In function `zif_imagegif': /usr/src/php-4.3.7/ext/gd/gd.c(.text+0x3d24): undefined reference to `gdImageGifCtx' ext/gd/gd.lo: In function `zif_imagecolorat': /usr/src/php-4.3.7/ext/gd/gd.c:1874: undefined reference to `gdImageBoundsSafe' /usr/src/php-4.3.7/ext/gd/gd.c:1882: undefined reference to `gdImageBoundsSafe' ext/pdf/pdf.lo: In function `zif_pdf_open_memory_image': /usr/src/php-4.3.7/ext/pdf/pdf.c(.text+0x6067): undefined reference to `gdImageBoundsSafe' /usr/src/php-4.3.7/ext/pdf/pdf.c(.text+0x60aa): undefined reference to `gdImageBoundsSafe' *** Error code 1 I searched multipe mailing lists, no answer was provided. I also tried the latest snapshot: http://snaps.php.net/php4-STABLE-200406071230.tar.gz Same configure string, but the make and make install worked perfectly. Now my problem is that this _always_ works in the snapshots, but it's "messed up" in the stable release, which is why I thought I'd report it anyway. -- Edit bug report at http://bugs.php.net/?id=28675&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28675&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28675&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28675&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28675&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28675&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28675&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28675&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28675&r=support Expected behavior: http://bugs.php.net/fix.php?id=28675&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28675&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28675&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28675&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28675&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28675&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28675&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28675&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28675&r=float
#28675 [Fbk->Opn]: compiling with internal GD lib fails
ID: 28675 User updated by: till at klimpong dot com Reported By: till at klimpong dot com -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: FreeBSD 4.6 PHP Version: 4.3.7 New Comment: Yes I do. Previous Comments: [2004-06-07 16:35:07] [EMAIL PROTECTED] Do you have gd.h anywhere on your system beside the one found in the PHP directory? [2004-06-07 16:25:48] till at klimpong dot com Description: I'm using 4.3.7 stable. Configure string: ./configure \ --with-apxs=/usr/local/sbin/apxs \ --with-config-file-path=/usr/local/etc \ --enable-versioning \ --with-regex=system \ --with-pgsql \ --with-gd \ --enable-gd-native-ttf \ --with-freetype-dir=/usr/local \ --with-jpeg-dir=/usr/local \ --with-png-dir=/usr/local \ --with-zlib \ --with-bz2=/usr \ --with-mcrypt=/usr/local \ --with-mhash=/usr/local \ --with-pdflib=/usr/local \ --with-zlib-dir=/usr \ --with-jpeg-dir=/usr/local \ --with-png-dir=/usr/local \ --with-tiff-dir=/usr/local \ --with-mysql=/usr/local/mysql4 \ --with-expat-dir=/usr/local \ --with-xmlrpc \ --enable-xslt \ --with-xslt-sablot \ --enable-wddx \ --with-dom=/usr/local \ --enable-ftp \ --with-gettext=/usr/local \ --enable-mbregex \ --enable-bcmath \ --enable-sockets \ --enable-sysvsem \ --enable-sysvshm \ --enable-trans-sid \ --with-iconv=/usr/local \ --enable-exif \ --enable-track-vars \ --with-imap \ --with-mcal \ --with-pear \ --with-openssl=/usr/local \ --disable-ipv6 Make fails with: ext/gd/gd.lo: In function `zif_imagegif': /usr/src/php-4.3.7/ext/gd/gd.c(.text+0x3d24): undefined reference to `gdImageGifCtx' ext/gd/gd.lo: In function `zif_imagecolorat': /usr/src/php-4.3.7/ext/gd/gd.c:1874: undefined reference to `gdImageBoundsSafe' /usr/src/php-4.3.7/ext/gd/gd.c:1882: undefined reference to `gdImageBoundsSafe' ext/pdf/pdf.lo: In function `zif_pdf_open_memory_image': /usr/src/php-4.3.7/ext/pdf/pdf.c(.text+0x6067): undefined reference to `gdImageBoundsSafe' /usr/src/php-4.3.7/ext/pdf/pdf.c(.text+0x60aa): undefined reference to `gdImageBoundsSafe' *** Error code 1 I searched multipe mailing lists, no answer was provided. I also tried the latest snapshot: http://snaps.php.net/php4-STABLE-200406071230.tar.gz Same configure string, but the make and make install worked perfectly. Now my problem is that this _always_ works in the snapshots, but it's "messed up" in the stable release, which is why I thought I'd report it anyway. -- Edit this bug report at http://bugs.php.net/?id=28675&edit=1
#28675 [Fbk->Opn]: compiling with internal GD lib fails
ID: 28675 User updated by: till at klimpong dot com Reported By: till at klimpong dot com -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: FreeBSD 4.6 PHP Version: 4.3.7 New Comment: /usr/local/include/gd/gd.h.old /usr/local/include/libwmf/gd/gd.h /usr/local/include/libwmf/gd.h /usr/local/include/gd.h.old /usr/local/share/doc/libwmf/gd.html Did that, but it still failed. Do you think I need to remove it from within libwmf directory as well? Previous Comments: [2004-06-07 16:39:35] [EMAIL PROTECTED] Can you temporary remove that file and then try to configure/compile PHP. [2004-06-07 16:38:00] till at klimpong dot com Yes I do. [2004-06-07 16:35:07] [EMAIL PROTECTED] Do you have gd.h anywhere on your system beside the one found in the PHP directory? [2004-06-07 16:25:48] till at klimpong dot com Description: I'm using 4.3.7 stable. Configure string: ./configure \ --with-apxs=/usr/local/sbin/apxs \ --with-config-file-path=/usr/local/etc \ --enable-versioning \ --with-regex=system \ --with-pgsql \ --with-gd \ --enable-gd-native-ttf \ --with-freetype-dir=/usr/local \ --with-jpeg-dir=/usr/local \ --with-png-dir=/usr/local \ --with-zlib \ --with-bz2=/usr \ --with-mcrypt=/usr/local \ --with-mhash=/usr/local \ --with-pdflib=/usr/local \ --with-zlib-dir=/usr \ --with-jpeg-dir=/usr/local \ --with-png-dir=/usr/local \ --with-tiff-dir=/usr/local \ --with-mysql=/usr/local/mysql4 \ --with-expat-dir=/usr/local \ --with-xmlrpc \ --enable-xslt \ --with-xslt-sablot \ --enable-wddx \ --with-dom=/usr/local \ --enable-ftp \ --with-gettext=/usr/local \ --enable-mbregex \ --enable-bcmath \ --enable-sockets \ --enable-sysvsem \ --enable-sysvshm \ --enable-trans-sid \ --with-iconv=/usr/local \ --enable-exif \ --enable-track-vars \ --with-imap \ --with-mcal \ --with-pear \ --with-openssl=/usr/local \ --disable-ipv6 Make fails with: ext/gd/gd.lo: In function `zif_imagegif': /usr/src/php-4.3.7/ext/gd/gd.c(.text+0x3d24): undefined reference to `gdImageGifCtx' ext/gd/gd.lo: In function `zif_imagecolorat': /usr/src/php-4.3.7/ext/gd/gd.c:1874: undefined reference to `gdImageBoundsSafe' /usr/src/php-4.3.7/ext/gd/gd.c:1882: undefined reference to `gdImageBoundsSafe' ext/pdf/pdf.lo: In function `zif_pdf_open_memory_image': /usr/src/php-4.3.7/ext/pdf/pdf.c(.text+0x6067): undefined reference to `gdImageBoundsSafe' /usr/src/php-4.3.7/ext/pdf/pdf.c(.text+0x60aa): undefined reference to `gdImageBoundsSafe' *** Error code 1 I searched multipe mailing lists, no answer was provided. I also tried the latest snapshot: http://snaps.php.net/php4-STABLE-200406071230.tar.gz Same configure string, but the make and make install worked perfectly. Now my problem is that this _always_ works in the snapshots, but it's "messed up" in the stable release, which is why I thought I'd report it anyway. -- Edit this bug report at http://bugs.php.net/?id=28675&edit=1
#28675 [Fbk->Opn]: compiling with internal GD lib fails
ID: 28675 User updated by: till at klimpong dot com Reported By: till at klimpong dot com -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: FreeBSD 4.6 PHP Version: 4.3.7 New Comment: Ok, renamed the rest, did a 'make clean' and it all went through. I did a "make test", email is the same as on here. Strange. Is this "fixable"? Cheers, Till Previous Comments: [2004-06-08 09:52:42] [EMAIL PROTECTED] Yes, and use a fresh copy of the PHP sources (as our configure stuff already found out about those other gd.h files). ---- [2004-06-07 18:19:00] till at klimpong dot com /usr/local/include/gd/gd.h.old /usr/local/include/libwmf/gd/gd.h /usr/local/include/libwmf/gd.h /usr/local/include/gd.h.old /usr/local/share/doc/libwmf/gd.html Did that, but it still failed. Do you think I need to remove it from within libwmf directory as well? [2004-06-07 16:39:35] [EMAIL PROTECTED] Can you temporary remove that file and then try to configure/compile PHP. ---- [2004-06-07 16:38:00] till at klimpong dot com Yes I do. [2004-06-07 16:35:07] [EMAIL PROTECTED] Do you have gd.h anywhere on your system beside the one found in the PHP directory? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/28675 -- Edit this bug report at http://bugs.php.net/?id=28675&edit=1
#34047 [Com]: When compile php cannot generate libphp5.so
ID: 34047 Comment by: till at klimpong dot com Reported By: calvinscy at hotmail dot com Status: No Feedback Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 5.0.4 New Comment: I'm having the same issue (it didn't build libphp5.so) with the 5.1.1 when I downloaded it from the website. My OS: FreeBSD 4.11-stable My libtool is: 1.5.x Using the latest snapshot solves this problem, but I am wondering why. Happy to provide more feedback when asked. :-) Previous Comments: [2005-08-28 21:26:21] rob at silverarcher dot com sunfreeware doesn't work either. I'm using Fedora Core 4 and cannot get this one part to compile. [2005-08-28 21:12:45] rob at silverarcher dot com The problem still seems to be occurring. php-5.0.4 and php- latest both will not compile the libphp5.so. I'm hoping sunfreeware.com can help... [2005-08-17 01:00:03] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-08-09 10:21:22] [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-08-09 09:47:08] calvinscy at hotmail dot com Description: When compiling the php5.0.4 download from your site, it cannot generate a file called libphp5.so. But if I download php-5.0.4.tar.gz from sunfreeware.com it can. After "make install" completed I can see the libphp5.so created under apache2/modules directory. I try the php4 from your site as well, it cannot generate libphp5.so too! -- Edit this bug report at http://bugs.php.net/?id=34047&edit=1
