Bug #62183 [Opn->Csd]: http content header missing
Edit report at https://bugs.php.net/bug.php?id=62183&edit=1 ID: 62183 User updated by:chris at topnotes dot net Reported by:chris at topnotes dot net Summary:http content header missing -Status: Open +Status: Closed Type: Bug Package:Zlib related Operating System: OSX 10.6 PHP Version:5.4.3 Block user comment: N Private report: N New Comment: seems to be fixed in 5.4.5 Previous Comments: [2012-05-29 19:25:06] chris at topnotes dot net I've downloaded PHP 5.3.13 and compiled that with my installation of Apache httpd 2.4.2 (ie replacing PHP 5.4.3). Output compression now working fine. So looks like something wrong with zlib in 5.4.3 (I'm not a C programmer, but zlib.c looks very different in 5.4.3 compared with 5.3.13). [2012-05-29 12:23:03] chris at topnotes dot net Description: My current production set up is PHP 5.3.10 and Apache 2.2.22, both of which I downloaded source for and compiled myself on OSX 10.6. I've now downloaded and compiled the source for PHP 5.3.4 and using this with Apache 2.4.2 I have zlib output compression enabled in php.ini. I'm using the same php.ini with both the 5.3.10 and 5.4.3 versions. With the 5.3.4 version, the zlib compression doesn't seem to be working. There is no http header "Content-Encoding: gzip" in my generated pages, which there is when I use the 5.3.10 software. Pages also taking much longer to deliver and load, which again suggests that compression is not working. >From the phpinfo output, the zlib settings are the same, but I notice that >php5.3.10 has zlib version 1.2.3.3, yet php 5.4.3 has zlib 1.2.3 5.3.10 : === zlib ZLib Supportenabled Stream Wrapper support compress.zlib:// Stream Filter support zlib.inflate, zlib.deflate Compiled Version1.2.3.3 Linked Version 1.2.3.3 Directive Local Value Master Value zlib.output_compression On On zlib.output_compression_level -1 -1 zlib.output_handler no valueno value PHP 5.4.3 = zlib ZLib Supportenabled Stream Wrapper compress.zlib:// Stream Filter zlib.inflate, zlib.deflate Compiled Version1.2.3 Linked Version 1.2.3 Directive Local Value Master Value zlib.output_compression On On zlib.output_compression_level -1 -1 zlib.output_handler no valueno value Also from the phpinfo pages, with 5.3.10 I see differencein the HTTP HEADERS INFORMATION (HTTP response headers) section : PHP 5.3.10 : === X-Powered-ByPHP/5.3.10 Content-Encodinggzip VaryAccept-Encoding PHP 5.4.3 : X-Powered-ByPHP/5.4.3 -- Edit this bug report at https://bugs.php.net/bug.php?id=62183&edit=1
[PHP-BUG] Bug #62656 [NEW]: Undefined reference to SSLv2 variables with OpenSSL 1.0.1
From: mattj at emazestudios dot com Operating system: Linux PHP version: 5.3.15 Package: OpenSSL related Bug Type: Bug Bug description:Undefined reference to SSLv2 variables with OpenSSL 1.0.1 Description: When compiling either 5.3.15 or 5.4.5 (or even 5.3 latest snapshot) with OpenSSL 1.0.1c, get the following error: ext/openssl/xp_ssl.o: In function `php_openssl_setup_crypto': /root/php-5.4.5/ext/openssl/xp_ssl.c:363: undefined reference to `SSLv2_server_method' /root/php-5.4.5/ext/openssl/xp_ssl.c:338: undefined reference to `SSLv2_client_method' collect2: ld returned 1 exit status Apparently this is due to the removal of SSLv2 in OpenSSL, and the extension doesn't seem to properly pick up which versions miss it. Using --with-openssl=/usr, but also occurs with --with-openssl alone. uname -m = x86_64 uname -r = 3.2.0-26-generic uname -s = Linux uname -v = #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC 2012 Autoconf 2.65 I can provide any sort of debugging help needed, as I would very much like to get this issue sorted. Can provide a full config.log on request, same as any make output. Seems very similar to bug #54507, however that's supposedly resolved quite a while ago. Expected result: Normal compilation with OpenSSL module Actual result: -- Compilation errors as shown above -- Edit bug report at https://bugs.php.net/bug.php?id=62656&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62656&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62656&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62656&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62656&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62656&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62656&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62656&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62656&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62656&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62656&r=support Expected behavior: https://bugs.php.net/fix.php?id=62656&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62656&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62656&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62656&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62656&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62656&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62656&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62656&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62656&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62656&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62656&r=mysqlcfg
Bug #62654 [Opn->Csd]: PHP-5.4.5 FPM SAPI doesn't compile on Solaris.
Edit report at https://bugs.php.net/bug.php?id=62654&edit=1 ID: 62654 Updated by: ras...@php.net Reported by:mike at maytech dot net Summary:PHP-5.4.5 FPM SAPI doesn't compile on Solaris. -Status: Open +Status: Closed Type: Bug Package:FPM related Operating System: Solaris PHP Version:master-Git-2012-07-24 (Git) -Assigned To: +Assigned To:rasmus Block user comment: N Private report: N New Comment: As the spam-flood of git commit messages should tell you, this has been fixed. Previous Comments: [2012-07-25 00:07:43] cataphr...@php.net Automatic comment on behalf of rasmus Revision: http://git.php.net/?p=php-src.git;a=commit;h=5799ebdb0cafb2de1dbb18cfe780976c98dbaeac Log: Fix bug #62654 [2012-07-24 23:40:52] ras...@php.net Automatic comment on behalf of rasmus Revision: http://git.php.net/?p=php-src.git;a=commit;h=0fbc8561e687689f796d95584cea1fa959eee83b Log: Fix bug #62654 [2012-07-24 23:35:50] ras...@php.net Automatic comment on behalf of rasmus Revision: http://git.php.net/?p=php-src.git;a=commit;h=a05e07ea1f75b8021c9b64bf93ff970873375d97 Log: Fix bug #62654 [2012-07-24 23:28:57] ras...@php.net Automatic comment on behalf of rasmus Revision: http://git.php.net/?p=php-src.git;a=commit;h=5f224412fa6892645ca548ac75f20ff8743ed916 Log: Fix bug #62654 [2012-07-24 23:09:07] mike at maytech dot net Description: PHP-5.4.5 FPM SAPI doesn't compile on Solaris due to interference of "sun" variable name in fpm_socket_unix_test_connect() function and the compiler's "sun" define so Solaris O/S. Patch attached. Expected result: Clean compilation Actual result: -- Doesn't compile -- Edit this bug report at https://bugs.php.net/bug.php?id=62654&edit=1
[PHP-BUG] Req #62655 [NEW]: Request: optional class name case-sensitivity
From: eric at wepay dot com
Operating system: OS X, CentOS
PHP version: Irrelevant
Package: Class/Object related
Bug Type: Feature/Change Request
Bug description:Request: optional class name case-sensitivity
Description:
It would be beneficial in more complex applications to be able to opt-in to
case
sensitive class names. It's very common to put classes in their own files
where
the filename matches the class name (namespaced classes often residing in
subdirectories).
However, the lack of case-sensitivity makes it easy to create very rare and
subtle bugs in applications: development is often done on case-insensitive
filesystems, and deployed to a case-sensitive production environment. While
the
obvious answer here is to develop in an environment identical to
production,
it's often impractical if not impossible to use a case-sensitive filesystem
on a
dev machine. Other behavior in autoloaders can have similar harmful
effects,
especially when new code paths cause scripts or classes to be loaded in a
different order.
I am not proposing that this become the default behavior, as it would
obviously
break countless applications. It should also not modify
__autoload/spl_autoload_register in any way. It would be nice to be able to
selectively enable this via php.ini:
; Enable class name case sensitivity
; 0 (default): class names are case-insensitive
; 1: class names are case-insensitive, but using a class name in a way
different
from its declaration will issue an E_STRICT warning including file and line
of
class name misuse
; 2: class names are case-sensitive. "class a {}" and "class A {}" can
coexist;
"A::foo()" and "a:foo()" are two separate calls
class_name_sensitivity = 0
I'm aware this has been discussed before (as early as 2003,
https://bugs.php.net/bug.php?id=26575&edit=1), however web app development
has
come a long way in nearly a decade and I think it's worth re-examining
this,
especially since it should be possible to do in a non-breaking manner.
--
Edit bug report at https://bugs.php.net/bug.php?id=62655&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62655&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62655&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62655&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62655&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62655&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62655&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62655&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62655&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62655&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62655&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62655&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62655&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62655&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62655&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62655&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62655&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62655&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62655&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62655&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62655&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62655&r=mysqlcfg
[PHP-BUG] Bug #62654 [NEW]: PHP-5.4.5 FPM SAPI doesn't compile on Solaris.
From: mike at maytech dot net Operating system: Solaris PHP version: master-Git-2012-07-24 (Git) Package: FPM related Bug Type: Bug Bug description:PHP-5.4.5 FPM SAPI doesn't compile on Solaris. Description: PHP-5.4.5 FPM SAPI doesn't compile on Solaris due to interference of "sun" variable name in fpm_socket_unix_test_connect() function and the compiler's "sun" define so Solaris O/S. Patch attached. Expected result: Clean compilation Actual result: -- Doesn't compile -- Edit bug report at https://bugs.php.net/bug.php?id=62654&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62654&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62654&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62654&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62654&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62654&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62654&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62654&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62654&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62654&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62654&r=support Expected behavior: https://bugs.php.net/fix.php?id=62654&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62654&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62654&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62654&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62654&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62654&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62654&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62654&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62654&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62654&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62654&r=mysqlcfg
Req #62582 [Opn]: xmlrpc_server_* should handle exceptions
Edit report at https://bugs.php.net/bug.php?id=62582&edit=1
ID: 62582
User updated by:gmblar+php at gmail dot com
Reported by:gmblar+php at gmail dot com
Summary:xmlrpc_server_* should handle exceptions
Status: Open
Type: Feature/Change Request
-Package:*XML functions
+Package:XMLRPC-EPI related
PHP Version:5.4.4
Block user comment: N
Private report: N
New Comment:
Change package
Previous Comments:
[2012-07-16 21:16:06] gmblar+php at gmail dot com
Description:
xmlrpc_server_* should handle exceptions and return a xmlrpc fault
Test script:
---
faultString
foobar
faultCode
42
Actual result:
--
Fatal error: Uncaught exception 'Exception' with message 'foobar' in -:5
Stack trace:
#0 [internal function]: {closure}('foo.bar', Array, Array)
#1 -(9): xmlrpc_server_call_method(Resource id #1, 'https://bugs.php.net/bug.php?id=62582&edit=1
Bug #62653 [Opn]: unset(array($foo)) crashes apache depending on $foo
Edit report at https://bugs.php.net/bug.php?id=62653&edit=1
ID: 62653
Updated by: s...@php.net
Reported by:davidso1 at rose-hulman dot edu
Summary:unset(array($foo)) crashes apache depending on $foo
Status: Open
Type: Bug
Package:Apache2 related
Operating System: Windows Server
PHP Version:5.4.5
Block user comment: N
Private report: N
New Comment:
The testcase produces invalid reads & writes in valgrind.
Previous Comments:
[2012-07-24 16:16:05] davidso1 at rose-hulman dot edu
Description:
The test code crashes apache in the 5.4+ environment.
$foo starts as a string, gets interpreted as a double but it isn't I guess.
unset($array[(double) $foo]) works as expected
Test script:
---
$array = array("5"=>"bar");
$foo = "10."; // gettype($foo) = "string"
$foo /= 2; //Makes $foo = 5 but still gettype($foo) = "double"
unset($array[$foo]);
print_r($array);
Expected result:
Array()
Actual result:
--
Error 101 (net::ERR_CONNECTION_RESET): The connection was reset.
--
Edit this bug report at https://bugs.php.net/bug.php?id=62653&edit=1
Bug #61044 [Com]: invalid PHP_BINDIR
Edit report at https://bugs.php.net/bug.php?id=61044&edit=1 ID: 61044 Comment by: martin dot leucht at gmail dot com Reported by:bugzilla33 at gmail dot com Summary:invalid PHP_BINDIR Status: Assigned Type: Bug Package:Unknown/Other Function Operating System: win 7 PHP Version:5.4.0RC7 Assigned To:pajoye Block user comment: N Private report: N New Comment: Just to mention: On my configuration (PHP 5.4.4, Win 7) at least the value for PHP_BINARY is correct. Maybe this helps to create a work-around. Previous Comments: [2012-02-11 11:10:04] johan...@php.net rk, that is correct, but on non-Windows you usually don't relocate the installation. Either you install using your package manager or by compiling yourself with a proper prefix, everything else is unsupported. On Windows we have the installer (which defaults to c:\program files\php (system dependent)) and the zip where people almost certainly won't use c:\php [2012-02-11 08:30:04] rk at srsbiz dot pl It is not only Windows problem: root@core /# /root/src/php5.4-201202102030/sapi/cli/php -r 'echo PHP_BINDIR . PHP_EOL;'; /usr/local/php54/bin root@core /# It always point to directory provided in --prefix at compile time. [2012-02-10 22:19:06] johan...@php.net This is defined while compiling PHP (prefix-option from compile.js), the way to fix this would be to do some run-time detection, not sure whether there's a proper way. [2012-02-10 18:05:38] anon at anon dot anon He's right. This seems to be totally broken on Windows: C:\>server\php\php.exe --version PHP 5.3.2 (cli) (built: Mar 3 2010 19:40:13) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans C:\>server\php\php.exe -r "echo PHP_BINDIR"; C:\php5 [2012-02-10 13:42:02] bugzilla33 at gmail dot com Description: Install php in folder c:\Php5 As module apache Test script: --- Expected result: c:\Php5 Actual result: -- c:\Php -- Edit this bug report at https://bugs.php.net/bug.php?id=61044&edit=1
Bug #51929 [Com]: Extracted a zip file that contains a folder named with Chinese characters
Edit report at https://bugs.php.net/bug.php?id=51929&edit=1 ID: 51929 Comment by: gazambuja at gmail dot com Reported by:kgo_yoi at hotmail dot com Summary:Extracted a zip file that contains a folder named with Chinese characters Status: Assigned Type: Bug Package:Zip Related Operating System: Windows XP Simplified Chinese PHP Version:5.2.13 Assigned To:pajoye Block user comment: N Private report: N New Comment: Some news about this bug? Also affect extracting zip files with non-english filename encode. Previous Comments: [2012-06-11 12:11:33] mikhail dot v dot gavrilov at gmail dot com I think this is not ZipArchive problem, it is problem zip archive format which not stored source code page, but extracting software interprets the code page in different ways depending on the platform (Windows uses DOS encoding ex. Cyrillic for 866, Linux uses UTF-8) [2012-06-08 03:53:53] maxspeed40k at gmail dot com windows 7 (32bit) php 5.4 [2011-08-24 05:36:52] chrodos at gmail dot com I also confirm this bug in the Greek language. The problem is that it has severe implications in popular opensource applications like moodle. Please read related bug: http://tracker.moodle.org/browse/MDL-24928 [2011-05-30 08:51:41] mikhail dot v dot gavrilov at gmail dot com I also confirm this problem. Workaround: Helps converting to your DOS encoding. [2011-02-18 14:05:12] paj...@php.net At some point the library will support UTF-8 (as zip specs allow that). But it is not yet implemented. 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 https://bugs.php.net/bug.php?id=51929 -- Edit this bug report at https://bugs.php.net/bug.php?id=51929&edit=1
[PHP-BUG] Bug #62653 [NEW]: unset(array($foo)) crashes apache depending on $foo
From: davidso1 at rose-hulman dot edu
Operating system: Windows Server
PHP version: 5.4.5
Package: Apache2 related
Bug Type: Bug
Bug description:unset(array($foo)) crashes apache depending on $foo
Description:
The test code crashes apache in the 5.4+ environment.
$foo starts as a string, gets interpreted as a double but it isn't I
guess.
unset($array[(double) $foo]) works as expected
Test script:
---
$array = array("5"=>"bar");
$foo = "10."; // gettype($foo) = "string"
$foo /= 2; //Makes $foo = 5 but still gettype($foo) = "double"
unset($array[$foo]);
print_r($array);
Expected result:
Array()
Actual result:
--
Error 101 (net::ERR_CONNECTION_RESET): The connection was reset.
--
Edit bug report at https://bugs.php.net/bug.php?id=62653&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62653&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62653&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62653&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62653&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62653&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62653&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62653&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62653&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62653&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62653&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62653&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62653&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62653&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62653&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62653&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62653&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62653&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62653&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62653&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62653&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62653&r=mysqlcfg
[PHP-BUG] Bug #62652 [NEW]: Make fails because of missing files
From: mike at saymikeo dot com Operating system: OSX Lion PHP version: 5.3.15 Package: Compile Failure Bug Type: Bug Bug description:Make fails because of missing files Description: creating libtool appending configuration tag "CXX" to libtool configure: creating ./config.status config.status: creating config.h running: make /bin/sh /private/tmp/pear/temp/pear-build-rootpwFTIe/trader-0.2.1/libtool -- mode=compile cc -I. -I/private/tmp/pear/temp/trader -DPHP_ATOM_INC - I/private/tmp/pear/temp/pear-build-rootpwFTIe/trader-0.2.1/include - I/private/tmp/pear/temp/pear-build-rootpwFTIe/trader-0.2.1/main - I/private/tmp/pear/temp/trader -I/usr/include/php -I/usr/include/php/main - I/usr/include/php/TSRM -I/usr/include/php/Zend -I/usr/include/php/ext - I/usr/include/php/ext/date/lib -I/private/tmp/pear/temp/trader/ta-lib/include - I/private/tmp/pear/temp/trader/ta-lib/src/ta_common - I/private/tmp/pear/temp/trader/functions -DHAVE_CONFIG_H -g -O2 -c /private/tmp/pear/temp/trader/ta-lib/src/ta_common/ta_global.c -o ta- lib/src/ta_common/ta_global.lo /private/tmp/pear/temp/pear-build-rootpwFTIe/trader-0.2.1/libtool: line 1280: ta- lib/src/ta_common/ta_global.loT: No such file or directory mkdir ta-lib/src/ta_common/.libs mkdir: ta-lib/src/ta_common: No such file or directory make: *** [ta-lib/src/ta_common/ta_global.lo] Error 1 ERROR: `make' failed Merges-iMac:etc mike$ which php /usr/bin/php Merges-iMac:etc mike$ php -version PHP 5.3.10 with Suhosin-Patch (cli) (built: Feb 20 2012 22:55:53) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies Test script: --- pecl install trader-beta -- Edit bug report at https://bugs.php.net/bug.php?id=62652&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62652&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62652&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62652&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62652&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62652&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62652&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62652&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62652&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62652&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62652&r=support Expected behavior: https://bugs.php.net/fix.php?id=62652&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62652&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62652&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62652&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62652&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62652&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62652&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62652&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62652&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62652&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62652&r=mysqlcfg
Bug #62651 [Fbk->Opn]: Extensions out of PHP source tree does not build anymore (link problem)
Edit report at https://bugs.php.net/bug.php?id=62651&edit=1
ID: 62651
User updated by:carlo dot pastorino at neologica dot it
Reported by:carlo dot pastorino at neologica dot it
Summary:Extensions out of PHP source tree does not build
anymore (link problem)
-Status: Feedback
+Status: Open
Type: Bug
Package:Compile Failure
Operating System: Windows 7
PHP Version:5.4.5
Block user comment: N
Private report: N
New Comment:
Thank you "cataphract" that solved the issue !! ;-)
I was actually including only "php.h" and changing that to:
extern "C"
{
#include "php.h"
}
did the trick.
I'm however quite confused, this same #include worked well for php5.3 without
the "extern" thing.
I took a look at, for example, "zend.h" header and I saw that all the
declaration marked as ZEND_API are also
wrapped by the "BEGIN_EXTERN_C()" and "END_EXTERN_C()" macros, but, inside the
header "zend_string.h" which is
the one causing me this link problem, all the ZEND_API declaration are not
wrapped by those 2 macros.
Is there some particular reason for this ?
I also found that, now that you've enlightened me, another solution to my
problem is to wrap those function in
the zend_string.h like this:
BEGIN_EXTERN_C() // was missing previosly
ZEND_API extern const char *(*zend_new_interned_string)(const char *str, int
len, int free_src TSRMLS_DC);
ZEND_API extern void (*zend_interned_strings_snapshot)(TSRMLS_D);
ZEND_API extern void (*zend_interned_strings_restore)(TSRMLS_D);
END_EXTERN_C() // was missing previosly
But in this case I really don't know if it works by chance or if it was really
meant to be like it was before.
Thank you for you help!
Carlo Pastorino.
Previous Comments:
[2012-07-24 12:18:12] cataphr...@php.net
Judging by the name of the symbol the linker can't find (namely it's name
mangling), it's pretty obvious you're compiling your project as C++. Make sure
you're including the PHP headers inside an extern "C" {} block.
[2012-07-24 12:15:42] paj...@php.net
No idea about sln, it may differ as phpize generates some data.
About another test, can you try to build it with php?
php-sdk\vc9\x86
|_ php-src
|_ pecl
|_ yourext
run buildconf from php-src, then:
configure
etc.
[2012-07-24 11:48:56] carlo dot pastorino at neologica dot it
Tested with phpize too and I obtained the same result. By the way the "phpize"
way is simply
not feasible for me/us and, if phpize makes it, Visual Studio should be able to
make it too,
right ?.
Please find my "phpize" project here :
http://www.neologica.it/test_ext_phpize.7z
I must admint I never used phpize before on windows and I didn't think it was
fully Windows
compatible, however here is what I did (everything is provided with the 7z
archive):
1] Created the "test" folder under "php_5.4/include/ext"
2] Moved my source files in this folder
3] Created the config.w32 file
4] Opened the Visual Studio 2008 command prompt and moved to this folder
5] ..\..\..\phpize.bat
6] configure.bat --enable-test (here I had to add "bison.exe" location to my
"PATH" and in
the configure.js file I needed to add PHP_PGI and PHP_PGO definition)
7] nmake
and the result was the same as before.
Microsoft (R) Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.
/out:test_class.exe
/out:Release_TS\php_test.dll
/dll
/libpath:C:\php_5.4\lib\;C:\php_5.4
Release_TS\php_5.4\include\ext\test\test_class.obj
Release_TS\php_5.4\include\ext\test\test_ext.obj
C:\php_5.4\lib\php5ts.lib
kernel32.lib
ole32.lib
user32.lib
advapi32.lib
shell32.lib
ws2_32.lib
Dnsapi.lib
Release_TS\php_test.dll.res
Creating library Release_TS\php_test.lib and object Release_TS\php_test.exp
test_class.obj : error LNK2019: unresolved external symbol "__declspec(dllimport
) char const * (__cdecl* zend_new_interned_string)(char const *,int,int,void * *
*)" (__imp_?zend_new_interned_string@@3P6APBDPBDHHPAPAPAX@ZA) referenced in fun
ction "void __cdecl init_test_class(void * * *)" (?init_test_class@@YAXPAPAPAX@Z
)
Release_TS\php_test.dll : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN
\cl.exe"' : return code '0x2'
Stop.
Thank you in advance,
Carlo Pastorino
[2012-07-24 10:11:20] paj...@php.net
This callback is part of the build (while interned string are only implemented
in
NTS).
Please check a build of your ext using the supported ways, phpize or to build
with
php to double check the actual problem.
Req #62356 [Asn->Csd]: Add syslog support to mail.log (php_mail)
Edit report at https://bugs.php.net/bug.php?id=62356&edit=1 ID: 62356 Updated by: f...@php.net Reported by:michael at orlitzky dot com Summary:Add syslog support to mail.log (php_mail) -Status: Assigned +Status: Closed Type: Feature/Change Request Package:Mail related PHP Version:5.4Git-2012-06-18 (Git) Assigned To:fa Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Fixed in 5.4 and master - thanks for the patch! Previous Comments: [2012-06-18 18:50:11] michael at orlitzky dot com Description: The PHP error logs support logging to syslog. You simply set, error_log = syslog in php.ini, and PHP handles the rest. The new mail.log setting does not support this, however, so it is difficult to consolidate your logs if you use syslog. Setting, mail.log = syslog results in a file name 'syslog' in the current directory. -- Edit this bug report at https://bugs.php.net/bug.php?id=62356&edit=1
Req #62356 [Opn->Asn]: Add syslog support to mail.log (php_mail)
Edit report at https://bugs.php.net/bug.php?id=62356&edit=1 ID: 62356 Updated by: f...@php.net Reported by:michael at orlitzky dot com Summary:Add syslog support to mail.log (php_mail) -Status: Open +Status: Assigned Type: Feature/Change Request Package:Mail related PHP Version:5.4Git-2012-06-18 (Git) -Assigned To: +Assigned To:fa Block user comment: N Private report: N Previous Comments: [2012-06-18 18:50:11] michael at orlitzky dot com Description: The PHP error logs support logging to syslog. You simply set, error_log = syslog in php.ini, and PHP handles the rest. The new mail.log setting does not support this, however, so it is difficult to consolidate your logs if you use syslog. Setting, mail.log = syslog results in a file name 'syslog' in the current directory. -- Edit this bug report at https://bugs.php.net/bug.php?id=62356&edit=1
Bug #55544 [Com]: ob_gzhandler always conflicts with zlib.output_compression
Edit report at https://bugs.php.net/bug.php?id=55544&edit=1
ID: 55544
Comment by: bugs dot php at mohiva dot com
Reported by:diogin at gmail dot com
Summary:ob_gzhandler always conflicts with
zlib.output_compression
Status: Closed
Type: Bug
Package:Output Control
Operating System: Windows XP SP3 x86
PHP Version:5.4.0alpha3
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
Now, it works for me.
Previous Comments:
[2012-07-24 06:55:04] larue...@php.net
re-fixed agian...
[2012-07-24 06:44:41] larue...@php.net
Automatic comment on behalf of laruence
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=4c1e2bbd6f744b4048d4e0540ecc5dbe005494fe
Log: Re-fix bug #55544
[2012-07-24 06:42:27] larue...@php.net
Automatic comment on behalf of laruence
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=4c1e2bbd6f744b4048d4e0540ecc5dbe005494fe
Log: Re-fix bug #55544
[2012-07-24 06:17:34] larue...@php.net
here is the confusion(assuming -d output_handler=ob_gzhandler -d
zlib.output_compression=0) :
1. php.output_handler will change the ZLIGB(output_compression) before the zlib
RINIT
2. in zlib RINIT, we set the ZLIBG(output_compression) to default value(ini)
3. if we don't override the ZLIBG(output_compression), then in the
php_zlib_output_compression_start which will be called in RINT will try to
start
zlib compression handler (although it depends on the requeset header), then,
the
conflict warning will be threw.
4. if we override it, then it the php_zlib_output_compression_start, it will
return FALIURE, and no compression occurred(see the codes from my previous
reply)
so, the key problem is multi-featrues depends on one global flag ->
ZLIBG(output_compression).
[2012-07-24 05:12:35] larue...@php.net
Here is the problem
ext/zlib/zlib.c
@@ -205,7 +205,7 @@ static int php_zlib_output_handler(void **handler_context,
php_output_context *o
if (SUCCESS ==
php_output_handler_hook(PHP_OUTPUT_HANDLER_HOOK_GET_FLAGS, &flags TSRMLS_CC)) {
/* only run this once */
if (!(flags & PHP_OUTPUT_HANDLER_STARTED)) {
if (SG(headers_sent) ||
!ZLIBG(output_compression)) {
seems we need a bigger work to resolve this
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
https://bugs.php.net/bug.php?id=55544
--
Edit this bug report at https://bugs.php.net/bug.php?id=55544&edit=1
Bug #62651 [Fbk]: Extensions out of PHP source tree does not build anymore (link problem)
Edit report at https://bugs.php.net/bug.php?id=62651&edit=1
ID: 62651
Updated by: cataphr...@php.net
Reported by:carlo dot pastorino at neologica dot it
Summary:Extensions out of PHP source tree does not build
anymore (link problem)
Status: Feedback
Type: Bug
Package:Compile Failure
Operating System: Windows 7
PHP Version:5.4.5
Block user comment: N
Private report: N
New Comment:
Judging by the name of the symbol the linker can't find (namely it's name
mangling), it's pretty obvious you're compiling your project as C++. Make sure
you're including the PHP headers inside an extern "C" {} block.
Previous Comments:
[2012-07-24 12:15:42] paj...@php.net
No idea about sln, it may differ as phpize generates some data.
About another test, can you try to build it with php?
php-sdk\vc9\x86
|_ php-src
|_ pecl
|_ yourext
run buildconf from php-src, then:
configure
etc.
[2012-07-24 11:48:56] carlo dot pastorino at neologica dot it
Tested with phpize too and I obtained the same result. By the way the "phpize"
way is simply
not feasible for me/us and, if phpize makes it, Visual Studio should be able to
make it too,
right ?.
Please find my "phpize" project here :
http://www.neologica.it/test_ext_phpize.7z
I must admint I never used phpize before on windows and I didn't think it was
fully Windows
compatible, however here is what I did (everything is provided with the 7z
archive):
1] Created the "test" folder under "php_5.4/include/ext"
2] Moved my source files in this folder
3] Created the config.w32 file
4] Opened the Visual Studio 2008 command prompt and moved to this folder
5] ..\..\..\phpize.bat
6] configure.bat --enable-test (here I had to add "bison.exe" location to my
"PATH" and in
the configure.js file I needed to add PHP_PGI and PHP_PGO definition)
7] nmake
and the result was the same as before.
Microsoft (R) Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.
/out:test_class.exe
/out:Release_TS\php_test.dll
/dll
/libpath:C:\php_5.4\lib\;C:\php_5.4
Release_TS\php_5.4\include\ext\test\test_class.obj
Release_TS\php_5.4\include\ext\test\test_ext.obj
C:\php_5.4\lib\php5ts.lib
kernel32.lib
ole32.lib
user32.lib
advapi32.lib
shell32.lib
ws2_32.lib
Dnsapi.lib
Release_TS\php_test.dll.res
Creating library Release_TS\php_test.lib and object Release_TS\php_test.exp
test_class.obj : error LNK2019: unresolved external symbol "__declspec(dllimport
) char const * (__cdecl* zend_new_interned_string)(char const *,int,int,void * *
*)" (__imp_?zend_new_interned_string@@3P6APBDPBDHHPAPAPAX@ZA) referenced in fun
ction "void __cdecl init_test_class(void * * *)" (?init_test_class@@YAXPAPAPAX@Z
)
Release_TS\php_test.dll : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN
\cl.exe"' : return code '0x2'
Stop.
Thank you in advance,
Carlo Pastorino
[2012-07-24 10:11:20] paj...@php.net
This callback is part of the build (while interned string are only implemented
in
NTS).
Please check a build of your ext using the supported ways, phpize or to build
with
php to double check the actual problem.
[2012-07-24 09:50:26] carlo dot pastorino at neologica dot it
Description:
I have a PHP extension which adds some "native" functions and zend classes to
the PHP framework.
This extension is located out of the php source tree and it is built using a
Visual Studio 2008 project which
should set all the preprocessor definitions and .lib needed.
In order to build this extension i'm linking it to the php5ts.lib file included
inside the php-devel-pack (which
can be downloaded from here
http://windows.php.net/downloads/releases/archives/)
and, of course, including the
*.h files provided with the php-devel-pack.
My Visual Studio solution worked fine using php5.2 and php5.3 includes and libs
but it fails the compilation
using the php5.4 php-devel-pack.
In particular I receive a link error:
unresolved external symbol "__declspec(dllimport) char const * (__cdecl*
zend_new_interned_string)(char const
*,int,int,void * * *)" (__imp_?zend_new_interned_string@@3P6APBDPBDHHPAPAPAX@ZA)
as if that symbol were not available from the php5ts.lib file.
I've generated a simpler Visual Studio solution containing ALL the files needed
to build which should present
the issue.
The solution can be downloaded here:
http://www.neologica.it/test_ext_vc9.7z
The source code contains a simple php extension and a zend class declaration
(Test) having a method: "sayHello".
Com
Bug #62651 [Opn->Fbk]: Extensions out of PHP source tree does not build anymore (link problem)
Edit report at https://bugs.php.net/bug.php?id=62651&edit=1 ID: 62651 Updated by: paj...@php.net Reported by:carlo dot pastorino at neologica dot it Summary:Extensions out of PHP source tree does not build anymore (link problem) -Status: Open +Status: Feedback Type: Bug Package:Compile Failure Operating System: Windows 7 PHP Version:5.4.5 Block user comment: N Private report: N New Comment: No idea about sln, it may differ as phpize generates some data. About another test, can you try to build it with php? php-sdk\vc9\x86 |_ php-src |_ pecl |_ yourext run buildconf from php-src, then: configure etc. Previous Comments: [2012-07-24 11:48:56] carlo dot pastorino at neologica dot it Tested with phpize too and I obtained the same result. By the way the "phpize" way is simply not feasible for me/us and, if phpize makes it, Visual Studio should be able to make it too, right ?. Please find my "phpize" project here : http://www.neologica.it/test_ext_phpize.7z I must admint I never used phpize before on windows and I didn't think it was fully Windows compatible, however here is what I did (everything is provided with the 7z archive): 1] Created the "test" folder under "php_5.4/include/ext" 2] Moved my source files in this folder 3] Created the config.w32 file 4] Opened the Visual Studio 2008 command prompt and moved to this folder 5] ..\..\..\phpize.bat 6] configure.bat --enable-test (here I had to add "bison.exe" location to my "PATH" and in the configure.js file I needed to add PHP_PGI and PHP_PGO definition) 7] nmake and the result was the same as before. Microsoft (R) Incremental Linker Version 9.00.30729.01 Copyright (C) Microsoft Corporation. All rights reserved. /out:test_class.exe /out:Release_TS\php_test.dll /dll /libpath:C:\php_5.4\lib\;C:\php_5.4 Release_TS\php_5.4\include\ext\test\test_class.obj Release_TS\php_5.4\include\ext\test\test_ext.obj C:\php_5.4\lib\php5ts.lib kernel32.lib ole32.lib user32.lib advapi32.lib shell32.lib ws2_32.lib Dnsapi.lib Release_TS\php_test.dll.res Creating library Release_TS\php_test.lib and object Release_TS\php_test.exp test_class.obj : error LNK2019: unresolved external symbol "__declspec(dllimport ) char const * (__cdecl* zend_new_interned_string)(char const *,int,int,void * * *)" (__imp_?zend_new_interned_string@@3P6APBDPBDHHPAPAPAX@ZA) referenced in fun ction "void __cdecl init_test_class(void * * *)" (?init_test_class@@YAXPAPAPAX@Z ) Release_TS\php_test.dll : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN \cl.exe"' : return code '0x2' Stop. Thank you in advance, Carlo Pastorino [2012-07-24 10:11:20] paj...@php.net This callback is part of the build (while interned string are only implemented in NTS). Please check a build of your ext using the supported ways, phpize or to build with php to double check the actual problem. [2012-07-24 09:50:26] carlo dot pastorino at neologica dot it Description: I have a PHP extension which adds some "native" functions and zend classes to the PHP framework. This extension is located out of the php source tree and it is built using a Visual Studio 2008 project which should set all the preprocessor definitions and .lib needed. In order to build this extension i'm linking it to the php5ts.lib file included inside the php-devel-pack (which can be downloaded from here http://windows.php.net/downloads/releases/archives/) and, of course, including the *.h files provided with the php-devel-pack. My Visual Studio solution worked fine using php5.2 and php5.3 includes and libs but it fails the compilation using the php5.4 php-devel-pack. In particular I receive a link error: unresolved external symbol "__declspec(dllimport) char const * (__cdecl* zend_new_interned_string)(char const *,int,int,void * * *)" (__imp_?zend_new_interned_string@@3P6APBDPBDHHPAPAPAX@ZA) as if that symbol were not available from the php5ts.lib file. I've generated a simpler Visual Studio solution containing ALL the files needed to build which should present the issue. The solution can be downloaded here: http://www.neologica.it/test_ext_vc9.7z The source code contains a simple php extension and a zend class declaration (Test) having a method: "sayHello". Compiling it using the configuration *_5.3 should produce the dll correctly while using the *_5.4 configuration should trigger the link error. I'm not sure if this is some unfortunate case of undeclared macro in my code / solution, or if there is something that could be done in php source. Test script: --
Bug #62651 [Fbk->Opn]: Extensions out of PHP source tree does not build anymore (link problem)
Edit report at https://bugs.php.net/bug.php?id=62651&edit=1 ID: 62651 User updated by:carlo dot pastorino at neologica dot it Reported by:carlo dot pastorino at neologica dot it Summary:Extensions out of PHP source tree does not build anymore (link problem) -Status: Feedback +Status: Open Type: Bug Package:Compile Failure Operating System: Windows 7 PHP Version:5.4.5 Block user comment: N Private report: N New Comment: Tested with phpize too and I obtained the same result. By the way the "phpize" way is simply not feasible for me/us and, if phpize makes it, Visual Studio should be able to make it too, right ?. Please find my "phpize" project here : http://www.neologica.it/test_ext_phpize.7z I must admint I never used phpize before on windows and I didn't think it was fully Windows compatible, however here is what I did (everything is provided with the 7z archive): 1] Created the "test" folder under "php_5.4/include/ext" 2] Moved my source files in this folder 3] Created the config.w32 file 4] Opened the Visual Studio 2008 command prompt and moved to this folder 5] ..\..\..\phpize.bat 6] configure.bat --enable-test (here I had to add "bison.exe" location to my "PATH" and in the configure.js file I needed to add PHP_PGI and PHP_PGO definition) 7] nmake and the result was the same as before. Microsoft (R) Incremental Linker Version 9.00.30729.01 Copyright (C) Microsoft Corporation. All rights reserved. /out:test_class.exe /out:Release_TS\php_test.dll /dll /libpath:C:\php_5.4\lib\;C:\php_5.4 Release_TS\php_5.4\include\ext\test\test_class.obj Release_TS\php_5.4\include\ext\test\test_ext.obj C:\php_5.4\lib\php5ts.lib kernel32.lib ole32.lib user32.lib advapi32.lib shell32.lib ws2_32.lib Dnsapi.lib Release_TS\php_test.dll.res Creating library Release_TS\php_test.lib and object Release_TS\php_test.exp test_class.obj : error LNK2019: unresolved external symbol "__declspec(dllimport ) char const * (__cdecl* zend_new_interned_string)(char const *,int,int,void * * *)" (__imp_?zend_new_interned_string@@3P6APBDPBDHHPAPAPAX@ZA) referenced in fun ction "void __cdecl init_test_class(void * * *)" (?init_test_class@@YAXPAPAPAX@Z ) Release_TS\php_test.dll : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN \cl.exe"' : return code '0x2' Stop. Thank you in advance, Carlo Pastorino Previous Comments: [2012-07-24 10:11:20] paj...@php.net This callback is part of the build (while interned string are only implemented in NTS). Please check a build of your ext using the supported ways, phpize or to build with php to double check the actual problem. [2012-07-24 09:50:26] carlo dot pastorino at neologica dot it Description: I have a PHP extension which adds some "native" functions and zend classes to the PHP framework. This extension is located out of the php source tree and it is built using a Visual Studio 2008 project which should set all the preprocessor definitions and .lib needed. In order to build this extension i'm linking it to the php5ts.lib file included inside the php-devel-pack (which can be downloaded from here http://windows.php.net/downloads/releases/archives/) and, of course, including the *.h files provided with the php-devel-pack. My Visual Studio solution worked fine using php5.2 and php5.3 includes and libs but it fails the compilation using the php5.4 php-devel-pack. In particular I receive a link error: unresolved external symbol "__declspec(dllimport) char const * (__cdecl* zend_new_interned_string)(char const *,int,int,void * * *)" (__imp_?zend_new_interned_string@@3P6APBDPBDHHPAPAPAX@ZA) as if that symbol were not available from the php5ts.lib file. I've generated a simpler Visual Studio solution containing ALL the files needed to build which should present the issue. The solution can be downloaded here: http://www.neologica.it/test_ext_vc9.7z The source code contains a simple php extension and a zend class declaration (Test) having a method: "sayHello". Compiling it using the configuration *_5.3 should produce the dll correctly while using the *_5.4 configuration should trigger the link error. I'm not sure if this is some unfortunate case of undeclared macro in my code / solution, or if there is something that could be done in php source. Test script: --- 1 - Extract the archive 2 - Open the solution with Visual Studio (2008 or 2010 is the same) 3 - Select "Release_5.4" or "Debug_5.4" from the build Solution configurations dropdown 4 - Build the extension. Expected result: php_test.dll correctly built Actual result: -- error LNK2001: unreso
Req #52761 [Com]: include backtrace in web server log on fatal error
Edit report at https://bugs.php.net/bug.php?id=52761&edit=1 ID: 52761 Comment by: willem at stuursma dot name Reported by:freeman3 at centrum dot cz Summary:include backtrace in web server log on fatal error Status: Not a bug Type: Feature/Change Request Package:Apache2 related Operating System: opensuse PHP Version:5.3.3 Block user comment: N Private report: N New Comment: You can also use the APM extension, which will log all errors with their requests and stack traces to a database (including E_ERRORs). Still, should be fixed. Previous Comments: [2012-06-07 09:31:40] jl235 at kent dot ac dot uk It is currently *impossible* to get a backtrace in pure PHP. Fatal errors by their very definition, are pretty damn serious. A backtrace makes them easier to debug. If not add a stack trace to the log, at least allow it to be recorded, and retrieved by user code in 'register_shutdown_function'. Then users can chose to log it themselves. [2012-01-10 19:09:43] freeman3 at centrum dot cz Still no response? this feature would be very useful. I can't use xdebug in production environment... is this some zend server only feature? [2012-01-10 16:19:00] walovaton at yahoo dot com dot mx If you install xdebug you will get exactly what you want although it will make the execution somewhat slower (acceptable in development but maybe not in production). What I would like to see is a way to get a backtrace of the current point of execution in the PHP code in a similar way you get it from Java when you kill -3 the process ID. It doesn't die, instead it gives you a backtrace of what it's doing at that moment. Is there any way to do this?? I guess I should file a new enhancement request. [2011-02-20 21:31:04] freeman3 at centrum dot cz I totally agree with robin, i still don't get why it's marked as bogus. How do you trace fatal errors? I you use a framework and an error occurs in a framework code file (like modelAbstract.php, which almost every other file uses), the error message like fatal error occured in modelAbstract.php is totally useless [2010-11-04 20:11:23] robin at robindaugherty dot net "if you want you can implement your error logger in user space" I don't believe it's possible to implement an error logger for fatal errors in user space. I see this as a huge problem. I develop and run a large site using PHP. I have a user-space handler for all other errors, notices, etc., but fatal errors are uncatchable and the log entry is usually missing enough information to track down the problem. For example: Fatal error: ob_start(): Cannot use output buffering in output buffering display handlers in [...]/ErrorHandler.php on line 785 I've tried to find a way to detect this, and having the backtrace would help. This particular code is called to render hundreds of variable on the page before the fatal one (which is apparently a non-fatal error or notice occurring inside of ob_gzhandler). I just need the call stack that exists when the error occurs. This is especially true of production sites, where I try to get enough information to at least reproduce issues. I get backtraces and context information for non-fatal errors, but the fatal errors are more important. 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 https://bugs.php.net/bug.php?id=52761 -- Edit this bug report at https://bugs.php.net/bug.php?id=52761&edit=1
Req #62369 [Opn->Asn]: Segfault on json_encode(deeply_nested_array);
Edit report at https://bugs.php.net/bug.php?id=62369&edit=1 ID: 62369 Updated by: f...@php.net Reported by:arjen at react dot com Summary:Segfault on json_encode(deeply_nested_array); -Status: Open +Status: Assigned Type: Feature/Change Request Package:JSON related Operating System: CENTOS PHP Version:5.4.4 -Assigned To: +Assigned To:fa Block user comment: N Private report: N Previous Comments: [2012-06-25 06:10:51] larue...@php.net change to FR: add a max_depth limitation to json_encode [2012-06-21 08:01:41] larue...@php.net stack overflow... it's kind of no bug... anyway maybe we can introduce a new parameter `max_depth` to json_encode too. [2012-06-20 09:10:38] arjen at react dot com Description: Trying to json_encode a 50.000 levels deep nested array causes a segfault. Segfault occurs in PHP versions 5.2.0 - 5.2.17, 5.3.0 - 5.3.14, 5.4.0 - 5.4.4, see http://3v4l.org/uZOgV Found while trying to construct a testcase for json_last_error() == JSON_ERROR_DEPTH Test script: --- , val= , options=) at /home/edwin/rpm/BUILD/php-5.3.13/ext/json/json.c:258 #4 php_json_encode (buf=, val=, options=) at /home/edwin/rpm/BUILD/php- 5.3.13/ext/json/json.c:476 #5 0x7fffed1e32df in json_encode_array (buf=, val= , options=) at /home/edwin/rpm/BUILD/php-5.3.13/ext/json/json.c:258 #6 php_json_encode (buf=, val=, options=) at /home/edwin/rpm/BUILD/php- 5.3.13/ext/json/json.c:476 #7 0x7fffed1e32df in json_encode_array (buf=, val= , options=) at /home/edwin/rpm/BUILD/php-5.3.13/ext/json/json.c:258 #8 php_json_encode (buf=, val=, options=) at /home/edwin/rpm/BUILD/php- 5.3.13/ext/json/json.c:476 #9 0x7fffed1e32df in json_encode_array (buf=, val= , options=) at /home/edwin/rpm/BUILD/php-5.3.13/ext/json/json.c:258 #10 php_json_encode (buf=, val=, options=) at /home/edwin/rpm/BUILD/php- 5.3.13/ext/json/json.c:476 [line 9/10 repeated] -- Edit this bug report at https://bugs.php.net/bug.php?id=62369&edit=1
Req #32100 [Csd->ReO]: Request 'finally' support for exceptions
Edit report at https://bugs.php.net/bug.php?id=32100&edit=1
ID: 32100
Updated by: larue...@php.net
Reported by:ceefour at gauldong dot net
Summary:Request 'finally' support for exceptions
-Status: Closed
+Status: Re-Opened
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
Operating System: *
PHP Version:5.*
-Assigned To:
+Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
I will try to make a implemention.
Previous Comments:
[2012-07-18 23:13:07] pieceofchum at yahoo dot com
Hello I am a Java developer and would like to move over to PHP for my current
personal projects. The use of finally in Java is extremely powerful as it
ensures that a unit of work that uses any resources that need to be managed are
guaranteed to be handled before leaving the method even whent here is a catch
clause. This has nothing to do with control flow and exception handling it has
everything to do with contract based blocks of code in fact finally is a
totally unique construct which greatly simplifies algorithms where one needs a
guarantee of certain code running (usually to handle external resources) no
matter what happens outside of course of an error (error defined as something
that breaks the interpreter/compiler/environmen). It is not a mistake of design
but a vast improvement in code clarity and application of the DRY principle
which is correct programming and has nothing at all to do with improper control
flow. It is not a mistake that it is in some form in Python, Ruby, Java etc...
Please please recondsider adding this extremely important construct to PHP.
Thanks for your consideration in this matter
[2012-07-05 20:17:57] angelo at camargo dot ws
++ for finally in PHP
[2012-06-07 09:16:55] jl235 at kent dot ac dot uk
Most of the exceptions people come across in their PHP code tends to be for
either File IO, or database access. Both of these need a finally to ensure the
handle/connection/whatever gets closed, or dealt with in some other way. Using
try/catch is already a lot more cumbersome then a world without Exceptions, but
without finally, it adds a lot duplication and state management.
For example in my own code I do something along the lines of ...
$time = microtime( true );
$sql = generateSQLQuery();
$conn = openDBConnection();
$ex = null;
try {
$result = runSQLQuery( $conn, $sql );
} catch ( Exception $ex ) { /* do nothing */ }
closeDBConnection( $conn );
logSQLQuery( $sql, microtime(true) - $time );
if ( $ex !== null ) {
throw $ex;
}
... which could just be ...
$time = microtime( true );
$sql = generateSQLQuery();
$conn = openDBConnection();
try {
$result = runSQLQuery( $conn, $sql );
} finally {
closeDBConnection( $conn );
logSQLQuery( $sql, microtime(true) - $time );
}
Simpler to write, easier to read, harder to get wrong, and more elegant.
Please re-open this.
[2012-06-05 11:19:41] sgnezdov at fastmail dot fm
Finally is absolutely necessary for proper management of disposable resources.
There is no easy to read workaround for
try {
causeException();
} finally {
releaseResource();
}
others pointed out that solving this issue kills re-throw, which is equally
important.
[2012-05-29 21:36:49] kavi at postpro dot net
Since every other kitchen sink on the planet has been thrown into PHP, why not
also the refrigerator which we all expect to be here? Come on. At least give
a
good reason.
Quoting topaz:
"Ugly workaround hack time!
(This is not a substitute for a real language feature!)"
...yeah, you're actually describing the *entire language* there. :|
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
https://bugs.php.net/bug.php?id=32100
--
Edit this bug report at https://bugs.php.net/bug.php?id=32100&edit=1
Bug #62651 [Opn->Fbk]: Extensions out of PHP source tree does not build anymore (link problem)
Edit report at https://bugs.php.net/bug.php?id=62651&edit=1 ID: 62651 Updated by: paj...@php.net Reported by:carlo dot pastorino at neologica dot it Summary:Extensions out of PHP source tree does not build anymore (link problem) -Status: Open +Status: Feedback Type: Bug Package:Compile Failure Operating System: Windows 7 PHP Version:5.4.5 Block user comment: N Private report: N New Comment: This callback is part of the build (while interned string are only implemented in NTS). Please check a build of your ext using the supported ways, phpize or to build with php to double check the actual problem. Previous Comments: [2012-07-24 09:50:26] carlo dot pastorino at neologica dot it Description: I have a PHP extension which adds some "native" functions and zend classes to the PHP framework. This extension is located out of the php source tree and it is built using a Visual Studio 2008 project which should set all the preprocessor definitions and .lib needed. In order to build this extension i'm linking it to the php5ts.lib file included inside the php-devel-pack (which can be downloaded from here http://windows.php.net/downloads/releases/archives/) and, of course, including the *.h files provided with the php-devel-pack. My Visual Studio solution worked fine using php5.2 and php5.3 includes and libs but it fails the compilation using the php5.4 php-devel-pack. In particular I receive a link error: unresolved external symbol "__declspec(dllimport) char const * (__cdecl* zend_new_interned_string)(char const *,int,int,void * * *)" (__imp_?zend_new_interned_string@@3P6APBDPBDHHPAPAPAX@ZA) as if that symbol were not available from the php5ts.lib file. I've generated a simpler Visual Studio solution containing ALL the files needed to build which should present the issue. The solution can be downloaded here: http://www.neologica.it/test_ext_vc9.7z The source code contains a simple php extension and a zend class declaration (Test) having a method: "sayHello". Compiling it using the configuration *_5.3 should produce the dll correctly while using the *_5.4 configuration should trigger the link error. I'm not sure if this is some unfortunate case of undeclared macro in my code / solution, or if there is something that could be done in php source. Test script: --- 1 - Extract the archive 2 - Open the solution with Visual Studio (2008 or 2010 is the same) 3 - Select "Release_5.4" or "Debug_5.4" from the build Solution configurations dropdown 4 - Build the extension. Expected result: php_test.dll correctly built Actual result: -- error LNK2001: unresolved external symbol "__declspec(dllimport) char const * (__cdecl* zend_new_interned_string)(char const *,int,int,void * * *)" (__imp_? zend_new_interned_string@@3P6APBDPBDHHPAPAPAX@ZA) -- Edit this bug report at https://bugs.php.net/bug.php?id=62651&edit=1
[PHP-BUG] Bug #62651 [NEW]: Extensions out of PHP source tree does not build anymore (link problem)
From: carlo dot pastorino at neologica dot it Operating system: Windows 7 PHP version: 5.4.5 Package: Compile Failure Bug Type: Bug Bug description:Extensions out of PHP source tree does not build anymore (link problem) Description: I have a PHP extension which adds some "native" functions and zend classes to the PHP framework. This extension is located out of the php source tree and it is built using a Visual Studio 2008 project which should set all the preprocessor definitions and .lib needed. In order to build this extension i'm linking it to the php5ts.lib file included inside the php-devel-pack (which can be downloaded from here http://windows.php.net/downloads/releases/archives/) and, of course, including the *.h files provided with the php-devel-pack. My Visual Studio solution worked fine using php5.2 and php5.3 includes and libs but it fails the compilation using the php5.4 php-devel-pack. In particular I receive a link error: unresolved external symbol "__declspec(dllimport) char const * (__cdecl* zend_new_interned_string)(char const *,int,int,void * * *)" (__imp_?zend_new_interned_string@@3P6APBDPBDHHPAPAPAX@ZA) as if that symbol were not available from the php5ts.lib file. I've generated a simpler Visual Studio solution containing ALL the files needed to build which should present the issue. The solution can be downloaded here: http://www.neologica.it/test_ext_vc9.7z The source code contains a simple php extension and a zend class declaration (Test) having a method: "sayHello". Compiling it using the configuration *_5.3 should produce the dll correctly while using the *_5.4 configuration should trigger the link error. I'm not sure if this is some unfortunate case of undeclared macro in my code / solution, or if there is something that could be done in php source. Test script: --- 1 - Extract the archive 2 - Open the solution with Visual Studio (2008 or 2010 is the same) 3 - Select "Release_5.4" or "Debug_5.4" from the build Solution configurations dropdown 4 - Build the extension. Expected result: php_test.dll correctly built Actual result: -- error LNK2001: unresolved external symbol "__declspec(dllimport) char const * (__cdecl* zend_new_interned_string)(char const *,int,int,void * * *)" (__imp_? zend_new_interned_string@@3P6APBDPBDHHPAPAPAX@ZA) -- Edit bug report at https://bugs.php.net/bug.php?id=62651&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62651&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62651&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62651&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62651&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62651&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62651&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62651&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62651&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62651&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62651&r=support Expected behavior: https://bugs.php.net/fix.php?id=62651&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62651&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62651&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62651&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62651&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62651&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62651&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62651&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62651&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62651&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62651&r=mysqlcfg
[PHP-BUG] Bug #62649 [NEW]: phar.phar.bat missing quotes
From: mlocati at gmail dot com Operating system: Windows 7 64 bit PHP version: 5.3.15 Package: PHAR related Bug Type: Bug Bug description:phar.phar.bat missing quotes Description: phar.phar.bat is missing double quotes: instead of %~dp0php.exe %~dp0pharcommand.phar %* we should have "%~dp0php.exe" "%~dp0pharcommand.phar" %* -- Edit bug report at https://bugs.php.net/bug.php?id=62649&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62649&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62649&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62649&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62649&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62649&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62649&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62649&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62649&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62649&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62649&r=support Expected behavior: https://bugs.php.net/fix.php?id=62649&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62649&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62649&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62649&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62649&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62649&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62649&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62649&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62649&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62649&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62649&r=mysqlcfg
Bug #62646 [Com]: Impossible to escape/match delimiters within \Q \E
Edit report at https://bugs.php.net/bug.php?id=62646&edit=1
ID: 62646
Comment by: Andreas dot Klauer at metamorpher dot de
Reported by:Andreas dot Klauer at metamorpher dot de
Summary:Impossible to escape/match delimiters within \Q \E
Status: Not a bug
Type: Bug
Package:PCRE related
PHP Version:5.3.15
Block user comment: N
Private report: N
New Comment:
But even if you escape the delimiter, it's not possible to match literal /#~ if
one of those is the delimiter; you have to escape it, but if you do escape it,
it matches literal \/#~ instead of just /#~.
Perl:
$subject = "foo/#~bar";
$subject =~ s/\Q\/#~\E/baz/;
print $subject;
=> "foobazbar"
PHP:
$subject = "foo/#~bar";
$subject = preg_replace("/\Q\/#~\E/", "baz", $subject);
echo $subject;
=> "foo/#~bar"
PHP tries to match literal \/#~ here.
Previous Comments:
[2012-07-24 01:55:35] fel...@php.net
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
Hi, the pcretest tool doesn't even handle the \Q..\E stuff as you mentioned. It
works just like the [..] one. And using Perl I did to escape the delimiter
inside \Q..\E.
[2012-07-24 00:33:54] Andreas dot Klauer at metamorpher dot de
Description:
PCRE allows literal matches of strings between \Q and \E. This is also
documented, \Q.$.\E will match literal .$.
However, if that literal string contains the regexp delimiter (/ or # or ~ or
() or whichever you choose), the regexp compile either fails, or the match
fails because it tries to match the escape char used to escape the delimiter.
The problem is php_pcre::pcre_get_compiled_regex_cache() which parses the
delimiter, not taking \Q \E in account. Delimiters between \Q \E should be
treated as literal characters, not delimiters (that's what Perl does); or
alternatively if delimiters have to be escaped, the escape char should be
removed from the pattern.
Workaround: Use preg_quote() instead of \Q \E if there's a chance the delimiter
may appear within \Q \E
Test script:
---
preg_replace("/\Q/#~\E/", ...);
=> Warning: preg_replace(): Unknown modifier '#' in php shell code on line 1
preg_replace("/\Q\/#~\E/", "OK", "/#~");
=> "/#~" (expected "OK")
preg_replace("/\Q\/#~\E/", "FAIL", "\/#~")
=> "FAIL" (expected "\/#~");
--
Edit this bug report at https://bugs.php.net/bug.php?id=62646&edit=1
Bug #62420 [Opn->Wfx]: Exception::__toString() creates message in wrong order if prev exception exists
Edit report at https://bugs.php.net/bug.php?id=62420&edit=1
ID: 62420
Updated by: f...@php.net
Reported by:bugs dot php at mohiva dot com
Summary:Exception::__toString() creates message in wrong
order if prev exception exists
-Status: Open
+Status: Wont fix
Type: Bug
Package:*General Issues
Operating System: Gentoo Linux
PHP Version:5.4.4
Block user comment: N
Private report: N
New Comment:
While you are correct that it might be more logical to reverse the order, this
isn't a huge problem.
Previous Comments:
[2012-06-26 11:56:09] bugs dot php at mohiva dot com
Description:
The method Exception::__toString() creates the message in the wrong order if a
previous exception exists in the Exception object.
The message contains the message from the previous exception as first and then
marked as next exception the message from the exception object itself. Normally
the message from the current exception should be the first message followed by
the previous message and so one.
Test script:
---
getPrevious()->getMessage() . '';
echo 'Current:' . $current->getMessage() . '';
echo 'String:' . $current->__toString() . '';
}
Expected result:
Previous: Previous exception
--
Current: Current exception
--
String: exception 'Exception' with message 'Current exception' in
exception.php:4 Stack trace: #0 {main} Next exception 'Exception' with message
'Previous exception' in exception.php:6 Stack trace: #0 {main}
Actual result:
--
Previous: Previous exception
--
Current: Current exception
--
String: exception 'Exception' with message 'Previous exception' in
exception.php:4 Stack trace: #0 {main} Next exception 'Exception' with message
'Current exception' in exception.php:6 Stack trace: #0 {main}
--
Edit this bug report at https://bugs.php.net/bug.php?id=62420&edit=1
