[PHP-BUG] Bug #60772 [NEW]: DB4/DB5 configure library lookup broken --build=x86_64-linux-gnu is passed
From:
Operating system: Ubuntu 11.10
PHP version: 5.3.9
Package: Compile Failure
Bug Type: Bug
Bug description:DB4/DB5 configure library lookup broken
--build=x86_64-linux-gnu is passed
Description:
First DB4/DB5 library lookup is far to simple.
Lookups are done for /usr/lib/libdb.a then /usr/lib/libdb.so in that
order.
First problem is there's no consideration of 'shared', which if specified
should
reverse the search looking for .so before .a as they usually both exist.
Second problem is when --build=x86_64-linux-gnu (or any other value) is
passed
no consideration is given. This means /usr/lib/x86_64-linux-gnu libraries
are
ignored.
Neither --with-libdir=/usr/lib/x86_64-linux-gnu or
--libdir=x86_64-linux-gnu
have any effect.
Third problem is diagnostics as many systems may have multiple copies of DB
installed. Be great to echo the info out of /usr/include/db.h as in...
DB_VERSION_{MAJOR,RELEASE,MINOR,PATCH} to clarify what's occurring.
Probably logic similar to libcurl is a good place to start.
Ugly fix is ln -s /usr/lib/x86_64-linux-gnu/libdb-5.1.so /usr/lib/.
Expected result:
Use all /usr/lib/(--build) libraries if --build is specified.
Actual result:
--
--build is ignored.
--
Edit bug report at https://bugs.php.net/bug.php?id=60772&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60772&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60772&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60772&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60772&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60772&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60772&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60772&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60772&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60772&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60772&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60772&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60772&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60772&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60772&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60772&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60772&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60772&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60772&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60772&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60772&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60772&r=mysqlcfg
[PHP-BUG] Bug #60812 [NEW]: Makefile INSTALL_IT target ignores --exec-prefix, --libexecdir, --sysconfdir
From:
Operating system: Ubuntu 11.10
PHP version: 5.3.9
Package: *Configuration Issues
Bug Type: Bug
Bug description:Makefile INSTALL_IT target ignores --exec-prefix, --libexecdir,
--sysconfdir
Description:
The INSTALL_IT target hardcodes apxs2 directories making it very difficult
to
install multiple versions of php or relocate php.
This also causes unexpected over writing of system php files, causing
Apache to
segfault.
Fixes are a bit complex because they involve configure + Makefile.
Suggest the end result produce a Makefile which honors these setting in all
cases. So Makefile should include...
sysconfdir=argument_passed_to_configure || /usr/lib/apache2/modules
libexecdir=${exec_prefix}/argument_passed_to_configure || /etc/apache2
INSTALL_IT target then changes to...
INSTALL_IT = $(mkinstalldirs) '$(INSTALL_ROOT)/$libexecdir' && \
$(mkinstalldirs) '$(INSTALL_ROOT)/$sysconfdir' && \
/usr/bin/apxs2 -S LIBEXECDIR='$(INSTALL_ROOT)/$libexecdir' \
-S SYSCONFDIR='$(INSTALL_ROOT)/$sysconfdir' \
-i -a -n php5 libphp5.la
--
Edit bug report at https://bugs.php.net/bug.php?id=60812&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60812&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60812&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60812&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60812&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60812&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60812&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60812&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60812&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60812&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60812&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60812&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60812&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60812&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60812&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60812&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60812&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60812&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60812&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60812&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60812&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60812&r=mysqlcfg
[PHP-BUG] Bug #60981 [NEW]: Shell environment inaccessible in tests
From: Operating system: Ubuntu 11.10 PHP version: 5.3.10 Package: Testing related Bug Type: Bug Bug description:Shell environment inaccessible in tests Description: Shell environment variables are not accessible via getenv() during tests. Test script: --- export MYSQL_TEST_PASSWD=... make test TESTS=ext/mysql*/tests/001.phpt Runs the mysql + mysqli connect tests and both are skipped. Tests are skipped showing... (using password: NO) Manually setting $passwd in connect.inc for both test sets runs all tests as expected. So MYSQL_TEST_PASSWD is ignored. -- Edit bug report at https://bugs.php.net/bug.php?id=60981&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60981&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60981&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60981&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60981&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60981&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60981&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60981&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60981&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60981&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60981&r=support Expected behavior: https://bugs.php.net/fix.php?id=60981&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60981&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60981&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60981&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60981&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60981&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60981&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60981&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60981&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60981&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60981&r=mysqlcfg
Bug #60981 [Fbk->Asn]: Shell environment inaccessible in tests
Edit report at https://bugs.php.net/bug.php?id=60981&edit=1 ID: 60981 User updated by:david at davidfavor dot com Reported by:david at davidfavor dot com Summary:Shell environment inaccessible in tests -Status: Feedback +Status: Assigned Type: Bug Package:Testing related Operating System: Ubuntu 11.10 PHP Version:5.3.10 Assigned To:danielc Block user comment: N Private report: N New Comment: export var=foo is the same as sourcing a file that includes... export var=foo Problem is no shell environment is reaching the test scripts. Please suggest a way to turn off clearing of the environment. Previous Comments: [2012-02-05 19:00:29] dani...@php.net The environment variables need to be established in a scope available all shell scripts. For example, them in the ~/.bashrc script of the user executing "make test". Set the variables in ~/.bashrc source ~/.bashrc make test The "source" step is only necessary in the first shell since the variables were not available when the shell was opened. All future shells will have them. ---- [2012-02-05 18:50:42] david at davidfavor dot com Description: Shell environment variables are not accessible via getenv() during tests. Test script: --- export MYSQL_TEST_PASSWD=... make test TESTS=ext/mysql*/tests/001.phpt Runs the mysql + mysqli connect tests and both are skipped. Tests are skipped showing... (using password: NO) Manually setting $passwd in connect.inc for both test sets runs all tests as expected. So MYSQL_TEST_PASSWD is ignored. -- Edit this bug report at https://bugs.php.net/bug.php?id=60981&edit=1
Bug #60981 [Asn]: Shell environment inaccessible in tests
Edit report at https://bugs.php.net/bug.php?id=60981&edit=1 ID: 60981 User updated by:david at davidfavor dot com Reported by:david at davidfavor dot com Summary:Shell environment inaccessible in tests Status: Assigned Type: Bug Package:Testing related Operating System: Ubuntu 11.10 PHP Version:5.3.10 Assigned To:danielc Block user comment: N Private report: N New Comment: That works... So there are two doc errors... #1) http://php.net/manual/en/reserved.variables.environment.php contains comments that getenv() returns environment variables, independent of variable_orders setting. I've submitted a note to clarify this. #2 http://php.net/manual/en/ini.core.php states variables_order default setting is "EGPCS", which is incorrect. Both php.ini-production and php.ini-development contain "GPCS". Best to fix both php.ini files so they match the docs. Let me know if I should open another bug request for the doc change. Thanks for helping me get this to work! Previous Comments: [2012-02-06 21:30:59] s...@php.net Try adding E to php.ini's variables_order. -------- [2012-02-06 20:12:20] david at davidfavor dot com export var=foo is the same as sourcing a file that includes... export var=foo Problem is no shell environment is reaching the test scripts. Please suggest a way to turn off clearing of the environment. [2012-02-05 19:00:29] dani...@php.net The environment variables need to be established in a scope available all shell scripts. For example, them in the ~/.bashrc script of the user executing "make test". Set the variables in ~/.bashrc source ~/.bashrc make test The "source" step is only necessary in the first shell since the variables were not available when the shell was opened. All future shells will have them. ---------------- [2012-02-05 18:50:42] david at davidfavor dot com Description: Shell environment variables are not accessible via getenv() during tests. Test script: --- export MYSQL_TEST_PASSWD=... make test TESTS=ext/mysql*/tests/001.phpt Runs the mysql + mysqli connect tests and both are skipped. Tests are skipped showing... (using password: NO) Manually setting $passwd in connect.inc for both test sets runs all tests as expected. So MYSQL_TEST_PASSWD is ignored. -- Edit this bug report at https://bugs.php.net/bug.php?id=60981&edit=1
Bug #60981 [Asn]: Shell environment inaccessible in tests
Edit report at https://bugs.php.net/bug.php?id=60981&edit=1
ID: 60981
User updated by:david at davidfavor dot com
Reported by:david at davidfavor dot com
Summary:Shell environment inaccessible in tests
Status: Assigned
Type: Bug
Package:Testing related
Operating System: Ubuntu 11.10
PHP Version:5.3.10
Assigned To:danielc
Block user comment: N
Private report: N
New Comment:
Seems like adding --d variable_orders=EGPCS to run-tests is the most elegant.
What the next step to arrange for this bug to be fixed?
Also I notice there are 4 failures in the mysqli tests. Let me know how to
register as a developer with php.net and I'll figure these out and supply
patches to fix the test suite.
Thanks.
Previous Comments:
[2012-02-07 15:03:35] tyr...@php.net
'Both php.ini-production and php.ini-development contain "GPCS".'
the default value means that what is the value if you don't set it any way
(having
no php.ini or using php -n for example)
unfortunately the default values and our developer/production inis aren't in
sync,
I brought that issue up on the mailing list in the past:
http://www.mail-archive.com/internals@lists.php.net/msg52262.html
[2012-02-07 14:59:11] jpa...@php.net
I confirm that getenv() works regardless any .ini config.
It proxies to SAPI/system getenv()
[2012-02-07 14:30:43] tyr...@php.net
the problem is that the run-tests.php fetches the environment variables from
$_ENV
http://svn.php.net/viewvc/php/php-src/trunk/run-tests.php?view=markup#l134
then passes the environment variables to the system_with_timeout call (which
will
proc_open using those environment variables).
so there is no documentation issue, only run-tests.php needs a change to either
force the variable_orders to contain E(we could pass the --d
variable_orders=EGPCS
in the run-tests.php call in http://svn.php.net/viewvc/php/php-
src/trunk/Makefile.global) or changing run-tests.php to not use the $_ENV array
for fetching all the environment vars.
[2012-02-07 14:18:14] tyr...@php.net
AFAIK getenv does work independently from variable_orders:
foo=bar php -d variables_order=GPC -r 'echo $_ENV["foo"];echo getenv("foo");'
outputs "bar" for me, so it works.
Tyrael
----------------
[2012-02-07 14:11:31] david at davidfavor dot com
That works...
So there are two doc errors...
#1) http://php.net/manual/en/reserved.variables.environment.php contains
comments
that getenv() returns environment variables, independent of variable_orders
setting. I've submitted a note to clarify this.
#2 http://php.net/manual/en/ini.core.php states variables_order default setting
is "EGPCS", which is incorrect.
Both php.ini-production and php.ini-development contain "GPCS".
Best to fix both php.ini files so they match the docs.
Let me know if I should open another bug request for the doc change.
Thanks for helping me get this to work!
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=60981
--
Edit this bug report at https://bugs.php.net/bug.php?id=60981&edit=1
Bug #60981 [Asn]: Shell environment inaccessible in tests
Edit report at https://bugs.php.net/bug.php?id=60981&edit=1 ID: 60981 User updated by:david at davidfavor dot com Reported by:david at davidfavor dot com Summary:Shell environment inaccessible in tests Status: Assigned Type: Bug Package:Testing related Operating System: Ubuntu 11.10 PHP Version:5.3.10 Assigned To:danielc Block user comment: N Private report: N New Comment: Just tested supplied patch and seems to work well. Previous Comments: [2012-02-07 15:57:10] tyr...@php.net The following patch has been added/updated: Patch Name: run-tests.php.diff Revision: 1328630230 URL: https://bugs.php.net/patch-display.php?bug=60981&patch=run-tests.php.diff&revision=1328630230 [2012-02-07 15:55:42] tyr...@php.net "--d variable_orders=EGPCS to run-tests" if you mean adding that to Makefile.global (the Makefile template, which will run run-tests.php when you execute make test) then yeah, it is an elegant solution, but I think it would be better to fix run-tests.php itself, so for those who call it directly (half of the core/qa people...) will also be fixed. Pierre told me that there is no clean way to fetch all environment vars from a php script if $_ENV isn't populated (you could parse it from the output of phpinfo() but that would be error-prone and messy). So I would propose calling another php instance and fetching the environment variables from there using shell_exec. See the attached patch. (If somebody has a better idea, I'm all for it.) -------- [2012-02-07 15:20:06] david at davidfavor dot com Seems like adding --d variable_orders=EGPCS to run-tests is the most elegant. What the next step to arrange for this bug to be fixed? Also I notice there are 4 failures in the mysqli tests. Let me know how to register as a developer with php.net and I'll figure these out and supply patches to fix the test suite. Thanks. [2012-02-07 15:03:35] tyr...@php.net 'Both php.ini-production and php.ini-development contain "GPCS".' the default value means that what is the value if you don't set it any way (having no php.ini or using php -n for example) unfortunately the default values and our developer/production inis aren't in sync, I brought that issue up on the mailing list in the past: http://www.mail-archive.com/internals@lists.php.net/msg52262.html [2012-02-07 14:59:11] jpa...@php.net I confirm that getenv() works regardless any .ini config. It proxies to SAPI/system getenv() 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=60981 -- Edit this bug report at https://bugs.php.net/bug.php?id=60981&edit=1
#50556 [NEW]: php build guru required to debug main/php_config.h generated incorrectly
From: david at davidfavor dot com Operating system: Ubuntu 9.10 PHP version: 5.3.1 PHP Bug Type: Compile Failure Bug description: php build guru required to debug main/php_config.h generated incorrectly Description: configure process generates different php_config.h files on different Ubuntu machines with identical packages installed (per dpkg -l). I've tried to decipher the ./configure process and have yet to figure it out. What I require is a php build guru to explain how to manually generate php_config.h from php_config.h.in to debug what's occurring. Thanks. Reproduce code: --- ./configure && make -- Edit bug report at http://bugs.php.net/?id=50556&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50556&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50556&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50556&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50556&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50556&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50556&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50556&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50556&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50556&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50556&r=support Expected behavior: http://bugs.php.net/fix.php?id=50556&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50556&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50556&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50556&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50556&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50556&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50556&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50556&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50556&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50556&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50556&r=mysqlcfg
#50538 [Bgs]: php_date.c compliation fails
ID: 50538 User updated by: david at davidfavor dot com Reported By: david at davidfavor dot com Status: Bogus Bug Type: Compile Failure Operating System: Ubuntu 9.10 PHP Version: 5.3.1 New Comment: This bug can be closed. I've opened a new bug 50556 to debug the real problem which is where main/php_config.h gets generated differently from main/php_config.h.in on multiple Ubuntu 9.10 machines where 'dpkg -l' reports identical packages installed. Previous Comments: [2009-12-21 02:41:46] ahar...@php.net This appears to be a problem with your build environment, rather than a PHP bug: PHP 5.3.1 builds fine on a stock Ubuntu 9.10 install, and the error you're getting is being generated deep within the system headers, rather than in anything specific to PHP. I suspect you'll have trouble compiling just about anything if including stdlib.h is causing problems. I would suggest following this up either with the PHP support options linked to by Daniel, or probably more productively, with one of Ubuntu's support options, such as their forums. Closing bug. [2009-12-20 20:34:06] degeb...@php.net Hi David, This is a problem with building PHP, not with building the documentation. I've reclassified the bug report for you so it will get to the right people. Personally, I have built PHP 5.3.1 from source on my Ubuntu 9.10 install, so it's probably your setup that is missing something. See http://www.php.net/support.php for support options. - Daniel -------- [2009-12-20 15:28:50] david at davidfavor dot com Description: The same problem appears with all stable versions of php (5.2.12, 5.3.0, 5.3.1) and Ubuntu Karmic with gcc-4.4.1 where php_date.c compilation fails. Reproduce code: --- r...@hive1:# ./configure r...@hive1:# make /bin/sh /home/dfavor/work/php-5.3.1/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/date/lib -Iext/date/ -I/home/dfavor/work/php-5.3.1/ext/date/ -DPHP_ATOM_INC -I/home/dfavor/work/php-5.3.1/include -I/home/dfavor/work/php-5.3.1/main -I/home/dfavor/work/php-5.3.1 -I/home/dfavor/work/php-5.3.1/ext/date/lib -I/home/dfavor/work/php-5.3.1/ext/ereg/regex -I/usr/include/libxml2 -I/home/dfavor/work/php-5.3.1/ext/sqlite3/libsqlite -I/home/dfavor/work/php-5.3.1/TSRM -I/home/dfavor/work/php-5.3.1/Zend -I/usr/include -g -O2 -fvisibility=hidden -c /home/dfavor/work/php-5.3.1/ext/date/php_date.c -o ext/date/php_date.lo In file included from /usr/include/stdlib.h:33, from /home/dfavor/work/php-5.3.1/include/../main/php_config.h:2845, from /home/dfavor/work/php-5.3.1/Zend/zend_config.h:1, from /home/dfavor/work/php-5.3.1/Zend/zend.h:51, from /home/dfavor/work/php-5.3.1/main/php.h:34, from /home/dfavor/work/php-5.3.1/ext/date/php_date.c:21: /usr/lib/gcc/i486-linux-gnu/4.4.1/include/stddef.h:211: error: duplicate 'unsigned' In file included from /usr/include/stdlib.h:320, from /home/dfavor/work/php-5.3.1/include/../main/php_config.h:2845, from /home/dfavor/work/php-5.3.1/Zend/zend_config.h:1, from /home/dfavor/work/php-5.3.1/Zend/zend.h:51, from /home/dfavor/work/php-5.3.1/main/php.h:34, from /home/dfavor/work/php-5.3.1/ext/date/php_date.c:21: /usr/include/sys/types.h:151: error: duplicate 'unsigned' /usr/include/sys/types.h:153: error: duplicate 'unsigned' /usr/include/sys/types.h:153: error: two or more data types in declaration specifiers make: *** [ext/date/php_date.lo] Error 1 r...@hive1:# uname -a Linux hive1.coolsurf.com 2.6.31-10-generic #35-Ubuntu SMP Tue Sep 22 17:33:42 UTC 2009 i686 GNU/Linux r...@hive1:# gcc --version gcc (Ubuntu 4.4.1-4ubuntu8) 4.4.1 r...@hive1:# libtool --version ltmain.sh (GNU libtool) 2.2.6 There are many ways of hacking this to work and I'd prefer someone in the know tell me the correct way to fix this. Thanks. -- Edit this bug report at http://bugs.php.net/?id=50538&edit=1
#50556 [Opn]: php build guru required to debug main/php_config.h generated incorrectly
ID: 50556 User updated by: david at davidfavor dot com Reported By: david at davidfavor dot com Status: Open Bug Type: Compile Failure Operating System: Ubuntu 9.10 PHP Version: 5.3.1 New Comment: I've reported this as a bug, rather than sending through the support mailing list because once this cause is determined, it's best guarded against as this problem is extremely difficult to debug. Previous Comments: [2009-12-22 22:09:57] david at davidfavor dot com Description: configure process generates different php_config.h files on different Ubuntu machines with identical packages installed (per dpkg -l). I've tried to decipher the ./configure process and have yet to figure it out. What I require is a php build guru to explain how to manually generate php_config.h from php_config.h.in to debug what's occurring. Thanks. Reproduce code: --- ./configure && make -- Edit this bug report at http://bugs.php.net/?id=50556&edit=1
#50556 [Opn]: php build guru required to debug main/php_config.h generated incorrectly
ID: 50556 User updated by: david at davidfavor dot com Reported By: david at davidfavor dot com Status: Open Bug Type: Compile Failure Operating System: Ubuntu 9.10 PHP Version: 5.3.1 New Comment: One example of this is... /* Define to `unsigned' if doesn't define. *//* Define to `unsigned' if doesn't define. */ /* #undef size_t */ | #define size_t unsigned The machine with #define size_t unsigned fails compiles with... /bin/sh /build/work/php-5.3.1/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/date/lib -Iext/date/ -I/build/work/php-5.3.1/ext/date/ -DPHP_ATOM_INC -I/build/work/php-5.3.1/include -I/build/work/php-5.3.1/main -I/build/work/php-5.3.1 -I/build/work/php-5.3.1/ext/date/lib -I/build/work/php-5.3.1/ext/ereg/regex -I/usr/include/libxml2 -I/build/work/php-5.3.1/ext/sqlite3/libsqlite -I/build/work/php-5.3.1/TSRM -I/build/work/php-5.3.1/Zend -I/usr/include -g -O2 -fvisibility=hidden -c /build/work/php-5.3.1/ext/date/php_date.c -o ext/date/php_date.lo In file included from /usr/include/stdlib.h:33, from /build/work/php-5.3.1/include/../main/php_config.h:2845, from /build/work/php-5.3.1/Zend/zend_config.h:1, from /build/work/php-5.3.1/Zend/zend.h:51, from /build/work/php-5.3.1/main/php.h:34, from /build/work/php-5.3.1/ext/date/php_date.c:21: /usr/lib/gcc/i486-linux-gnu/4.4.1/include/stddef.h:211: error: duplicate 'unsigned' In file included from /usr/include/stdlib.h:320, from /build/work/php-5.3.1/include/../main/php_config.h:2845, from /build/work/php-5.3.1/Zend/zend_config.h:1, from /build/work/php-5.3.1/Zend/zend.h:51, from /build/work/php-5.3.1/main/php.h:34, from /build/work/php-5.3.1/ext/date/php_date.c:21: /usr/include/sys/types.h:151: error: duplicate 'unsigned' /usr/include/sys/types.h:153: error: duplicate 'unsigned' /usr/include/sys/types.h:153: error: two or more data types in declaration specifiers make: *** [ext/date/php_date.lo] Error 1 And... maybe ./configure is picking this up wrong somehow so the autoheader process simply passes this along when php_config.h is created. Previous Comments: ---------------- [2009-12-22 22:13:22] david at davidfavor dot com I've reported this as a bug, rather than sending through the support mailing list because once this cause is determined, it's best guarded against as this problem is extremely difficult to debug. ---------------- [2009-12-22 22:09:57] david at davidfavor dot com Description: configure process generates different php_config.h files on different Ubuntu machines with identical packages installed (per dpkg -l). I've tried to decipher the ./configure process and have yet to figure it out. What I require is a php build guru to explain how to manually generate php_config.h from php_config.h.in to debug what's occurring. Thanks. Reproduce code: --- ./configure && make -- Edit this bug report at http://bugs.php.net/?id=50556&edit=1
#50556 [Bgs]: php build guru required to debug main/php_config.h generated incorrectly
ID: 50556 User updated by: david at davidfavor dot com Reported By: david at davidfavor dot com Status: Bogus Bug Type: Compile Failure Operating System: Ubuntu 9.10 PHP Version: 5.3.1 New Comment: It appears this is a configure problem. On the broken machine size_t is missed... r...@hive1:# grep size_t configure.log checking size of size_t... 4 checking size of ssize_t... 4 checking for size_t... no checking for size_t... (cached) no On the working machine... r...@hive2:# grep size_t configure.log checking size of size_t... 4 checking size of ssize_t... 4 checking for size_t... yes checking for size_t... (cached) yes Previous Comments: [2009-12-22 22:23:52] johan...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. The output depends on the libraries, environment variables the system (for instance 32 vs 64 bit, x86 vs. sparc, ...) so the output can be different easily For learning how to debug it learn about autoconf and automake. [2009-12-22 22:21:37] david at davidfavor dot com One example of this is... /* Define to `unsigned' if doesn't define. *//* Define to `unsigned' if doesn't define. */ /* #undef size_t */ | #define size_t unsigned The machine with #define size_t unsigned fails compiles with... /bin/sh /build/work/php-5.3.1/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/date/lib -Iext/date/ -I/build/work/php-5.3.1/ext/date/ -DPHP_ATOM_INC -I/build/work/php-5.3.1/include -I/build/work/php-5.3.1/main -I/build/work/php-5.3.1 -I/build/work/php-5.3.1/ext/date/lib -I/build/work/php-5.3.1/ext/ereg/regex -I/usr/include/libxml2 -I/build/work/php-5.3.1/ext/sqlite3/libsqlite -I/build/work/php-5.3.1/TSRM -I/build/work/php-5.3.1/Zend -I/usr/include -g -O2 -fvisibility=hidden -c /build/work/php-5.3.1/ext/date/php_date.c -o ext/date/php_date.lo In file included from /usr/include/stdlib.h:33, from /build/work/php-5.3.1/include/../main/php_config.h:2845, from /build/work/php-5.3.1/Zend/zend_config.h:1, from /build/work/php-5.3.1/Zend/zend.h:51, from /build/work/php-5.3.1/main/php.h:34, from /build/work/php-5.3.1/ext/date/php_date.c:21: /usr/lib/gcc/i486-linux-gnu/4.4.1/include/stddef.h:211: error: duplicate 'unsigned' In file included from /usr/include/stdlib.h:320, from /build/work/php-5.3.1/include/../main/php_config.h:2845, from /build/work/php-5.3.1/Zend/zend_config.h:1, from /build/work/php-5.3.1/Zend/zend.h:51, from /build/work/php-5.3.1/main/php.h:34, from /build/work/php-5.3.1/ext/date/php_date.c:21: /usr/include/sys/types.h:151: error: duplicate 'unsigned' /usr/include/sys/types.h:153: error: duplicate 'unsigned' /usr/include/sys/types.h:153: error: two or more data types in declaration specifiers make: *** [ext/date/php_date.lo] Error 1 And... maybe ./configure is picking this up wrong somehow so the autoheader process simply passes this along when php_config.h is created. ---------------- [2009-12-22 22:13:22] david at davidfavor dot com I've reported this as a bug, rather than sending through the support mailing list because once this cause is determined, it's best guarded against as this problem is extremely difficult to debug. ---------------- [2009-12-22 22:09:57] david at davidfavor dot com Description: configure process generates different php_config.h files on different Ubuntu machines with identical packages installed (per dpkg -l). I've tried to decipher the ./configure process and have yet to figure it out. What I require is a php build guru to explain how to manually generate php_config.h from php_config.h.in to debug what's occurring. Thanks. Reproduce code: --- ./configure && make -- Edit this bug report at http://bugs.php.net/?id=50556&edit=1
#50556 [Bgs]: php build guru required to debug main/php_config.h generated incorrectly
ID: 50556 User updated by: david at davidfavor dot com Reported By: david at davidfavor dot com Status: Bogus Bug Type: Compile Failure Operating System: Ubuntu 9.10 PHP Version: 5.3.1 New Comment: Bizarre. Some combination of package installations created symlinks from /bin/egrep to /bin/grep, so all egrep regular expressions were failing in configure. No clue how to check for this. Doing 'apt-get --reinstall install grep' fixed the problem. Close this bug. Previous Comments: [2009-12-22 22:29:01] david at davidfavor dot com It appears this is a configure problem. On the broken machine size_t is missed... r...@hive1:# grep size_t configure.log checking size of size_t... 4 checking size of ssize_t... 4 checking for size_t... no checking for size_t... (cached) no On the working machine... r...@hive2:# grep size_t configure.log checking size of size_t... 4 checking size of ssize_t... 4 checking for size_t... yes checking for size_t... (cached) yes [2009-12-22 22:23:52] johan...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. The output depends on the libraries, environment variables the system (for instance 32 vs 64 bit, x86 vs. sparc, ...) so the output can be different easily For learning how to debug it learn about autoconf and automake. [2009-12-22 22:21:37] david at davidfavor dot com One example of this is... /* Define to `unsigned' if doesn't define. *//* Define to `unsigned' if doesn't define. */ /* #undef size_t */ | #define size_t unsigned The machine with #define size_t unsigned fails compiles with... /bin/sh /build/work/php-5.3.1/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/date/lib -Iext/date/ -I/build/work/php-5.3.1/ext/date/ -DPHP_ATOM_INC -I/build/work/php-5.3.1/include -I/build/work/php-5.3.1/main -I/build/work/php-5.3.1 -I/build/work/php-5.3.1/ext/date/lib -I/build/work/php-5.3.1/ext/ereg/regex -I/usr/include/libxml2 -I/build/work/php-5.3.1/ext/sqlite3/libsqlite -I/build/work/php-5.3.1/TSRM -I/build/work/php-5.3.1/Zend -I/usr/include -g -O2 -fvisibility=hidden -c /build/work/php-5.3.1/ext/date/php_date.c -o ext/date/php_date.lo In file included from /usr/include/stdlib.h:33, from /build/work/php-5.3.1/include/../main/php_config.h:2845, from /build/work/php-5.3.1/Zend/zend_config.h:1, from /build/work/php-5.3.1/Zend/zend.h:51, from /build/work/php-5.3.1/main/php.h:34, from /build/work/php-5.3.1/ext/date/php_date.c:21: /usr/lib/gcc/i486-linux-gnu/4.4.1/include/stddef.h:211: error: duplicate 'unsigned' In file included from /usr/include/stdlib.h:320, from /build/work/php-5.3.1/include/../main/php_config.h:2845, from /build/work/php-5.3.1/Zend/zend_config.h:1, from /build/work/php-5.3.1/Zend/zend.h:51, from /build/work/php-5.3.1/main/php.h:34, from /build/work/php-5.3.1/ext/date/php_date.c:21: /usr/include/sys/types.h:151: error: duplicate 'unsigned' /usr/include/sys/types.h:153: error: duplicate 'unsigned' /usr/include/sys/types.h:153: error: two or more data types in declaration specifiers make: *** [ext/date/php_date.lo] Error 1 And... maybe ./configure is picking this up wrong somehow so the autoheader process simply passes this along when php_config.h is created. ---------------- [2009-12-22 22:13:22] david at davidfavor dot com I've reported this as a bug, rather than sending through the support mailing list because once this cause is determined, it's best guarded against as this problem is extremely difficult to debug. -------------------- [2009-12-22 22:09:57] david at davidfavor dot com Description: configure process generates different php_config.h files on different Ubuntu machines with identical packages installed (per dpkg -l). I've tried to decipher the ./configure process and have yet to figure it out. What I require is a php build guru to explain how to manually generate php_config.h from php_config.h.in to debug what
#36483 [NEW]: phpize php_autoconf security fix
From: david at davidfavor dot com Operating system: RedHat EL-4 PHP version: 5.1.2 PHP Bug Type: Feature/Change Request Bug description: phpize php_autoconf security fix Description: Since I've only installed PHP the first time, please route this the the correct place. There are many reports that resemble this: /usr/local/bin/phpize: /tmp/tmpEcSnL3/apd-1.0.1/build/shtool: /bin/sh: bad interpreter: Permission denied Cannot find autoconf. Please check your autoconf installation and the $PHP_AUTOCONF environment variable is set correctly and then rerun this script. ERROR: `phpize' failed The problem is the pear command seems to be be violate usual security precautions. That is mounting /tmp with the noexec option disallows the execution of /tmp/*/shtool. The fix seems to be maybe checking the executability of scripts on /tmp first and prompting the user for an alternative directory first. The ugly work around is to change /etc/fstab to allow /tmp files to be executed... Shudder... Reproduce code: --- 1) In /etc/fstab: /dev/hda3 /tmp ext3 defaults,noexec 1 0 2) reboot 3) pear install pecl/pdflib -- Edit bug report at http://bugs.php.net/?id=36483&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36483&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36483&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36483&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36483&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36483&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36483&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36483&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36483&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36483&r=support Expected behavior:http://bugs.php.net/fix.php?id=36483&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36483&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36483&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36483&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36483&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36483&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36483&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36483&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36483&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36483&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36483&r=mysqlcfg
