Bug #61057 [Fbk-Opn]: PHP 5.3.10 fails to cross compile when FPM is enabled (ptrace)
Edit report at https://bugs.php.net/bug.php?id=61057edit=1 ID: 61057 User updated by:d dot albano at gmail dot com Reported by:d dot albano at gmail dot com Summary:PHP 5.3.10 fails to cross compile when FPM is enabled (ptrace) -Status: Feedback +Status: Open Type: Bug Package:Compile Failure Operating System: Linux PHP Version:5.3.10 Block user comment: N Private report: N New Comment: I'm cross compiling because i'm building a set of images for boards like alix, routerboards and, when it will be out, raspberry pi too. I know that it may sound strange, but i don't want to put an entire distribution on the alix my 30mb systems works perfectly and has everything i need. Thank you, i'll do a test. Previous Comments: [2012-02-12 21:27:44] ras...@php.net Why are you cross-compiling to the same architecture? You may be able to solve this simply by using a newer version of autoconf to generate the configure script. As a quick test, try building the latest PHP 5.4 with a recent version of autoconf installed. (use ./buildconf --force to force re-generation of the configure script) For PHP 5.3 the latest you can use is autoconf-2.59 For PHP 5.4 the oldest you can use is autoconf-2.59 [2012-02-12 21:06:43] hotseason007 at gmail dot com I also reach it ,but php.net don't regard it as a bug ! here is my report: https://bugs.php.net/bug.php?id=61063 I have fix and Here is the guid: https://github.com/Qzi/webstore/wiki the page attaches the patch enjoy it !! [2012-02-11 17:15:22] d dot albano at gmail dot com Description: I'm trying to cross compile php 5.3.10 (build x86, host x86, target x86) but when i enable FPM i get the following error checking whether ptrace works... configure: error: can not run test program while cross compiling I know that FPM is experimental, btw the bug is related to configure script and not to FPM itself. Wihtout fpm, enabling only cgi and cli works fine Here more output, starting from SAPI modules Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... no checking for Apache 1.x module support... no checking whether to enable Apache charset compatibility option... no checking for Apache 2.0 filter-module support via DSO through APXS... no checking for Apache 2.0 handler-module support via DSO through APXS... no checking for Apache 1.x (hooks) module support via DSO through APXS... no checking for Apache 1.x (hooks) module support... no checking whether to enable Apache charset compatibility option... no checking for Caudium support... no checking for CLI build... yes checking for Continuity support... no checking for embedded SAPI library support... no checking for FPM build... yes checking for setenv... yes checking for clearenv... yes checking for setproctitle... no checking for library containing socket... none required checking for library containing inet_addr... none required checking for errno.h... yes checking for fcntl.h... yes checking for stdio.h... yes checking for stdlib.h... yes checking for unistd.h... yes checking for sys/uio.h... yes checking for sys/select.h... yes checking for sys/socket.h... yes checking for sys/time.h... yes checking for arpa/inet.h... yes checking for netinet/in.h... yes checking for prctl... yes checking for clock_gettime... yes checking for ptrace... yes checking whether ptrace works... configure: error: can not run test program while cross compiling make[1]: *** [/home/daniele/sviluppo/clew.js/br-rootfs/build/php- 5.3.10/.stamp_configured] Errore 1 make: *** [all] Errore 2 Expected result: it should go ahead Actual result: -- checking whether ptrace works... configure: error: can not run test program while cross compiling -- Edit this bug report at https://bugs.php.net/bug.php?id=61057edit=1
[PHP-BUG] Bug #61057 [NEW]: PHP 5.3.10 fails to cross compile when FPM is enabled (ptrace)
From: Operating system: Linux PHP version: 5.3.10 Package: Compile Failure Bug Type: Bug Bug description:PHP 5.3.10 fails to cross compile when FPM is enabled (ptrace) Description: I'm trying to cross compile php 5.3.10 (build x86, host x86, target x86) but when i enable FPM i get the following error checking whether ptrace works... configure: error: can not run test program while cross compiling I know that FPM is experimental, btw the bug is related to configure script and not to FPM itself. Wihtout fpm, enabling only cgi and cli works fine Here more output, starting from SAPI modules Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... no checking for Apache 1.x module support... no checking whether to enable Apache charset compatibility option... no checking for Apache 2.0 filter-module support via DSO through APXS... no checking for Apache 2.0 handler-module support via DSO through APXS... no checking for Apache 1.x (hooks) module support via DSO through APXS... no checking for Apache 1.x (hooks) module support... no checking whether to enable Apache charset compatibility option... no checking for Caudium support... no checking for CLI build... yes checking for Continuity support... no checking for embedded SAPI library support... no checking for FPM build... yes checking for setenv... yes checking for clearenv... yes checking for setproctitle... no checking for library containing socket... none required checking for library containing inet_addr... none required checking for errno.h... yes checking for fcntl.h... yes checking for stdio.h... yes checking for stdlib.h... yes checking for unistd.h... yes checking for sys/uio.h... yes checking for sys/select.h... yes checking for sys/socket.h... yes checking for sys/time.h... yes checking for arpa/inet.h... yes checking for netinet/in.h... yes checking for prctl... yes checking for clock_gettime... yes checking for ptrace... yes checking whether ptrace works... configure: error: can not run test program while cross compiling make[1]: *** [/home/daniele/sviluppo/clew.js/br-rootfs/build/php- 5.3.10/.stamp_configured] Errore 1 make: *** [all] Errore 2 Expected result: it should go ahead Actual result: -- checking whether ptrace works... configure: error: can not run test program while cross compiling -- Edit bug report at https://bugs.php.net/bug.php?id=61057edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61057r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61057r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61057r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61057r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61057r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61057r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61057r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61057r=needscript Try newer version: https://bugs.php.net/fix.php?id=61057r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61057r=support Expected behavior: https://bugs.php.net/fix.php?id=61057r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61057r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61057r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61057r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61057r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61057r=dst IIS Stability: https://bugs.php.net/fix.php?id=61057r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61057r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61057r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61057r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61057r=mysqlcfg
#41810 [Bgs-Opn]: Unable to catch Parse Errors
ID: 41810
User updated by: d dot albano at gmail dot com
Reported By: d dot albano at gmail dot com
-Status: Bogus
+Status: Open
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 5.2.3
New Comment:
Looking to the code looks simply to do the modification, naturally, as
you said, the problem is testing.
However i founded an eval behaviour to support my feature request: if
there is a parse error execution continues
Can be that this is a bug or an unwanted behaviour, however nothing
start to work strange after that a parse error was outputted.
So, if all works with eval why it shouldn't work correctly with normal
parse errors?
Here there is some example code:
?php
echo BEGIN;
eval('echo {$SYNTAX-ERROR');
echo END;
?
It output
BEGIN
Parse error: syntax error, unexpected '-', expecting '}' in
C:\web\htdocs\test.php(5) : eval()'d code on line 1
END
Previous Comments:
[2007-06-26 13:07:22] d dot albano at gmail dot com
When i said:
If it remains in a unstable state there is serious problem somewhere
i answered to your phrase:
After parse error the parser/compiler and whole engine may be in
unstable state
If parsing a file may put the entire engine in an unstable state there
is a problem: never heard that a parser can do this
The problem can be that the engine is written to shutdown after a
parser error and this is can cause troubles i think, but the problem is
that i'm not zend/php developer :)
However i don't think that is necessary to rewrite the engine from the
scracth, a feature like this, at logic level, must follow rules followed
by other errors
This afternoon i'll take a look to the parser and to the zend engine to
understand how errors are passed
Thanks a lot
Bye
[2007-06-26 12:43:06] [EMAIL PROTECTED]
If it remains in a unstable state there is serious problem somewhere
:\
I don't think so, but you're encouraged to help us, the sources are
open after all.
I'm sure nobody is going to rewrite the engine from scratch using some
other tools just because you want to catch parse errors.
So there is no sense to keep this feature request open.
[2007-06-26 12:34:37] d dot albano at gmail dot com
if parser, before to compile and execute, check the code to see if the
syntax is right how can remain the engine in an unstable state?
[2007-06-26 12:31:16] d dot albano at gmail dot com
If there is a parse error, this error stop parsing of scripting engine,
and this is ok, but where is the problem? And why it should remain in an
unstable state? This doesn't make sense: it's parsing php code ... it
isin't executing it
If it remains in a unstable state there is serious problem somewhere :\
[2007-06-26 11:49:38] [EMAIL PROTECTED]
After parse error the parser/compiler and whole engine may be in
unstable state, hence it's impossible to catch it as well as any other
fatal errors.
They are fatal errors just because of that.
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/41810
--
Edit this bug report at http://bugs.php.net/?id=41810edit=1
#41810 [NEW]: Unable to catch Parse Errors
From: d dot albano at gmail dot com
Operating system: Linux
PHP version: 5.2.3
PHP Bug Type: Scripting Engine problem
Bug description: Unable to catch Parse Errors
Description:
Hi,
i've seen that set_error_handler doesn't let to the code to catch Parse
Errors. I know that set_error_handler documentation page on php manual says
that this error can't be catched, so this isin't a true bug: it is
something like a logical bug because using strange tricks you can catch
parse errors for included files.
So, instead to force php developers to do strange tricks to catch parse
errors why don't try to send parse errors throught user defined error
handler, if it is setted? I know that this isin't so simply but it is
becoming necessary: in an advanced system is vitally catch any kind of
error that can cause problem to page execution and this comprises catching
every kind of errors that can be generated by third party module or every
included file.
I understand that there isin't an easy way to do but a point of start can
be define it through htaccess/php_value or simply use it only with included
files after that set_error_handler is setted
Reproduce code:
---
# main.php:
?php
function error_handler($errno, $errstr, $errfile, $errline)
{
echo 'error catched!';
}
set_error_handler('error_handler');
require_once('file_with_parse_error.php');
?
# file_with_parse_error.php:
?php
--- this is a voluntary php parse error ---
?
Expected result:
Browser should show:
error catched!
Actual result:
--
Browser output:
Parse error: syntax error,
--
Edit bug report at http://bugs.php.net/?id=41810edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41810r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41810r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41810r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41810r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41810r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41810r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41810r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41810r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41810r=support
Expected behavior:http://bugs.php.net/fix.php?id=41810r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41810r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41810r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41810r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41810r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41810r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41810r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41810r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41810r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41810r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41810r=mysqlcfg
#41810 [Bgs-Opn]: Unable to catch Parse Errors
ID: 41810
User updated by: d dot albano at gmail dot com
Reported By: d dot albano at gmail dot com
-Status: Bogus
+Status: Open
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 5.2.3
New Comment:
As i've said:
I understand that there isin't an easy way to do but a point of
start
can be define it through htaccess/php_value or simply use it only
with
included files after that set_error_handler is setted
Exactly for that reason: a file that is parsed can't rely on any
error_handler but if a file is included by another script that
initialize the error handler the stuff change becase the code is
executed normally and the file is included at runtime
Infact the code that i written refer exactly to this: check parse
errors on included files not on the main file.
It is normal that isn't possible to catch errors in main.php
Previous Comments:
[2007-06-26 11:21:38] [EMAIL PROTECTED]
it is something like a logical bug
It's something like a logical bug to catch parse errors using an error
handler defined in the same script, cause the parse error may happen in
the handler itself.
The parse error happens BEFORE execution starts, at the compilation
stage, so it's just phisically impossible to call something that does
not exist at that moment.
[2007-06-26 10:46:51] d dot albano at gmail dot com
Description:
Hi,
i've seen that set_error_handler doesn't let to the code to catch Parse
Errors. I know that set_error_handler documentation page on php manual
says that this error can't be catched, so this isin't a true bug: it is
something like a logical bug because using strange tricks you can catch
parse errors for included files.
So, instead to force php developers to do strange tricks to catch parse
errors why don't try to send parse errors throught user defined error
handler, if it is setted? I know that this isin't so simply but it is
becoming necessary: in an advanced system is vitally catch any kind of
error that can cause problem to page execution and this comprises
catching every kind of errors that can be generated by third party
module or every included file.
I understand that there isin't an easy way to do but a point of start
can be define it through htaccess/php_value or simply use it only with
included files after that set_error_handler is setted
Reproduce code:
---
# main.php:
?php
function error_handler($errno, $errstr, $errfile, $errline)
{
echo 'error catched!';
}
set_error_handler('error_handler');
require_once('file_with_parse_error.php');
?
# file_with_parse_error.php:
?php
--- this is a voluntary php parse error ---
?
Expected result:
Browser should show:
error catched!
Actual result:
--
Browser output:
Parse error: syntax error,
--
Edit this bug report at http://bugs.php.net/?id=41810edit=1
#41810 [Bgs-Opn]: Unable to catch Parse Errors
ID: 41810
User updated by: d dot albano at gmail dot com
Reported By: d dot albano at gmail dot com
-Status: Bogus
+Status: Open
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 5.2.3
New Comment:
If there is a parse error, this error stop parsing of scripting engine,
and this is ok, but where is the problem? And why it should remain in an
unstable state? This doesn't make sense: it's parsing php code ... it
isin't executing it
If it remains in a unstable state there is serious problem somewhere :\
Previous Comments:
[2007-06-26 11:49:38] [EMAIL PROTECTED]
After parse error the parser/compiler and whole engine may be in
unstable state, hence it's impossible to catch it as well as any other
fatal errors.
They are fatal errors just because of that.
[2007-06-26 11:30:34] d dot albano at gmail dot com
As i've said:
I understand that there isin't an easy way to do but a point of
start
can be define it through htaccess/php_value or simply use it only
with
included files after that set_error_handler is setted
Exactly for that reason: a file that is parsed can't rely on any
error_handler but if a file is included by another script that
initialize the error handler the stuff change becase the code is
executed normally and the file is included at runtime
Infact the code that i written refer exactly to this: check parse
errors on included files not on the main file.
It is normal that isn't possible to catch errors in main.php
[2007-06-26 11:21:38] [EMAIL PROTECTED]
it is something like a logical bug
It's something like a logical bug to catch parse errors using an error
handler defined in the same script, cause the parse error may happen in
the handler itself.
The parse error happens BEFORE execution starts, at the compilation
stage, so it's just phisically impossible to call something that does
not exist at that moment.
[2007-06-26 10:46:51] d dot albano at gmail dot com
Description:
Hi,
i've seen that set_error_handler doesn't let to the code to catch Parse
Errors. I know that set_error_handler documentation page on php manual
says that this error can't be catched, so this isin't a true bug: it is
something like a logical bug because using strange tricks you can catch
parse errors for included files.
So, instead to force php developers to do strange tricks to catch parse
errors why don't try to send parse errors throught user defined error
handler, if it is setted? I know that this isin't so simply but it is
becoming necessary: in an advanced system is vitally catch any kind of
error that can cause problem to page execution and this comprises
catching every kind of errors that can be generated by third party
module or every included file.
I understand that there isin't an easy way to do but a point of start
can be define it through htaccess/php_value or simply use it only with
included files after that set_error_handler is setted
Reproduce code:
---
# main.php:
?php
function error_handler($errno, $errstr, $errfile, $errline)
{
echo 'error catched!';
}
set_error_handler('error_handler');
require_once('file_with_parse_error.php');
?
# file_with_parse_error.php:
?php
--- this is a voluntary php parse error ---
?
Expected result:
Browser should show:
error catched!
Actual result:
--
Browser output:
Parse error: syntax error,
--
Edit this bug report at http://bugs.php.net/?id=41810edit=1
#41810 [Opn]: Unable to catch Parse Errors
ID: 41810
User updated by: d dot albano at gmail dot com
Reported By: d dot albano at gmail dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 5.2.3
New Comment:
if parser, before to compile and execute, check the code to see if the
syntax is right how can remain the engine in an unstable state?
Previous Comments:
[2007-06-26 12:31:16] d dot albano at gmail dot com
If there is a parse error, this error stop parsing of scripting engine,
and this is ok, but where is the problem? And why it should remain in an
unstable state? This doesn't make sense: it's parsing php code ... it
isin't executing it
If it remains in a unstable state there is serious problem somewhere :\
[2007-06-26 11:49:38] [EMAIL PROTECTED]
After parse error the parser/compiler and whole engine may be in
unstable state, hence it's impossible to catch it as well as any other
fatal errors.
They are fatal errors just because of that.
[2007-06-26 11:30:34] d dot albano at gmail dot com
As i've said:
I understand that there isin't an easy way to do but a point of
start
can be define it through htaccess/php_value or simply use it only
with
included files after that set_error_handler is setted
Exactly for that reason: a file that is parsed can't rely on any
error_handler but if a file is included by another script that
initialize the error handler the stuff change becase the code is
executed normally and the file is included at runtime
Infact the code that i written refer exactly to this: check parse
errors on included files not on the main file.
It is normal that isn't possible to catch errors in main.php
[2007-06-26 11:21:38] [EMAIL PROTECTED]
it is something like a logical bug
It's something like a logical bug to catch parse errors using an error
handler defined in the same script, cause the parse error may happen in
the handler itself.
The parse error happens BEFORE execution starts, at the compilation
stage, so it's just phisically impossible to call something that does
not exist at that moment.
[2007-06-26 10:46:51] d dot albano at gmail dot com
Description:
Hi,
i've seen that set_error_handler doesn't let to the code to catch Parse
Errors. I know that set_error_handler documentation page on php manual
says that this error can't be catched, so this isin't a true bug: it is
something like a logical bug because using strange tricks you can catch
parse errors for included files.
So, instead to force php developers to do strange tricks to catch parse
errors why don't try to send parse errors throught user defined error
handler, if it is setted? I know that this isin't so simply but it is
becoming necessary: in an advanced system is vitally catch any kind of
error that can cause problem to page execution and this comprises
catching every kind of errors that can be generated by third party
module or every included file.
I understand that there isin't an easy way to do but a point of start
can be define it through htaccess/php_value or simply use it only with
included files after that set_error_handler is setted
Reproduce code:
---
# main.php:
?php
function error_handler($errno, $errstr, $errfile, $errline)
{
echo 'error catched!';
}
set_error_handler('error_handler');
require_once('file_with_parse_error.php');
?
# file_with_parse_error.php:
?php
--- this is a voluntary php parse error ---
?
Expected result:
Browser should show:
error catched!
Actual result:
--
Browser output:
Parse error: syntax error,
--
Edit this bug report at http://bugs.php.net/?id=41810edit=1
#41810 [Bgs]: Unable to catch Parse Errors
ID: 41810 User updated by: d dot albano at gmail dot com Reported By: d dot albano at gmail dot com Status: Bogus Bug Type: Feature/Change Request Operating System: Linux PHP Version: 5.2.3 New Comment: When i said: If it remains in a unstable state there is serious problem somewhere i answered to your phrase: After parse error the parser/compiler and whole engine may be in unstable state If parsing a file may put the entire engine in an unstable state there is a problem: never heard that a parser can do this The problem can be that the engine is written to shutdown after a parser error and this is can cause troubles i think, but the problem is that i'm not zend/php developer :) However i don't think that is necessary to rewrite the engine from the scracth, a feature like this, at logic level, must follow rules followed by other errors This afternoon i'll take a look to the parser and to the zend engine to understand how errors are passed Thanks a lot Bye Previous Comments: [2007-06-26 12:43:06] [EMAIL PROTECTED] If it remains in a unstable state there is serious problem somewhere :\ I don't think so, but you're encouraged to help us, the sources are open after all. I'm sure nobody is going to rewrite the engine from scratch using some other tools just because you want to catch parse errors. So there is no sense to keep this feature request open. [2007-06-26 12:34:37] d dot albano at gmail dot com if parser, before to compile and execute, check the code to see if the syntax is right how can remain the engine in an unstable state? [2007-06-26 12:31:16] d dot albano at gmail dot com If there is a parse error, this error stop parsing of scripting engine, and this is ok, but where is the problem? And why it should remain in an unstable state? This doesn't make sense: it's parsing php code ... it isin't executing it If it remains in a unstable state there is serious problem somewhere :\ [2007-06-26 11:49:38] [EMAIL PROTECTED] After parse error the parser/compiler and whole engine may be in unstable state, hence it's impossible to catch it as well as any other fatal errors. They are fatal errors just because of that. [2007-06-26 11:30:34] d dot albano at gmail dot com As i've said: I understand that there isin't an easy way to do but a point of start can be define it through htaccess/php_value or simply use it only with included files after that set_error_handler is setted Exactly for that reason: a file that is parsed can't rely on any error_handler but if a file is included by another script that initialize the error handler the stuff change becase the code is executed normally and the file is included at runtime Infact the code that i written refer exactly to this: check parse errors on included files not on the main file. It is normal that isn't possible to catch errors in main.php 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/41810 -- Edit this bug report at http://bugs.php.net/?id=41810edit=1
