Req #52297 [Com]: visibility identifier namespace-protected
Edit report at http://bugs.php.net/bug.php?id=52297&edit=1
ID: 52297
Comment by: florent dot biville at insa-rouen dot fr
Reported by:giorgio dot liscio at email dot it
Summary:visibility identifier namespace-protected
Status: Wont fix
Type: Feature/Change Request
Package:Class/Object related
Operating System: all
PHP Version:5.3.2
Block user comment: N
Private report: N
New Comment:
I agree such a modifier is necessary.
>From an API designer point of view, how would it be possible to distinct
API classes/methods from classes/methods needed within (and only within)
the framework without this ?
This current limitation leads to unsafe overrides of internal
classes/methods.
Since PHP 5.3 now embeds namespaces, this modifier must be available.
Previous Comments:
[2010-07-16 14:03:25] giorgio dot liscio at email dot it
hi aharvey
i really want to contribute but my English is not good
i hope someone want to write an rfc
for anyone reads: feel free to write comments about this
[2010-07-16 07:09:44] ahar...@php.net
PHP namespaces really aren't meant to be anything more than a way of
avoiding name collisions and allowing aliasing -- visibility modifiers
are somewhat beyond the scope of what they're trying to achieve.
If you really want to push this, I'd suggest raising this on the
Internals mailing list (preferably with a prototype patch) with a view
to putting this through the RFC process instead, given it would be a
moderately significant language change.
[2010-07-09 02:56:36] giorgio dot liscio at email dot it
Description:
hi, in php is missing a visibility identifier to protect methods and
properties inside the namespace
example:
namespace Oracle; // abstraction layer for Oracle
class Connection
{
// ociresource should be visible only in the namespace
// in php 5.3 the property is public to world
namespace-protected $ociresource;
public function __construct()
{
$this->ociresource = oci_connect();
}
public function query($sql)
{
return new Query($this, $sql);
}
}
class Query
{
public function __construct(Connection $con, $sql)
{
$x = oci_parse($con->ociresource, $sql);// $ociresource is
accessible only in this namespace
oci_execute($x);
}
}
suggested visibility identifier:
namespace-private
(if namespace is \Test\Abc\ the method/property is only accessible
within \Test\Abc\)
namespace-protected
(if namespace is \Test\Abc\ the method/property can be accessible
within \Test\Abc\ and, for example \Test\Abc\Foo\ )
--
Edit this bug report at http://bugs.php.net/bug.php?id=52297&edit=1
Bug #54016 [Asn->Csd]: finfo_file: Cannot determine filetype in archives
Edit report at http://bugs.php.net/bug.php?id=54016&edit=1 ID: 54016 Updated by: bj...@php.net Reported by:bj...@php.net Summary:finfo_file: Cannot determine filetype in archives -Status: Assigned +Status: Closed Type: Bug Package:Filesystem function related Operating System: Linux PHP Version:5.3.5 Assigned To:bjori Block user comment: N Private report: N New Comment: Forgot to close this report.. already fixed in the 5.3.6 Previous Comments: [2011-02-14 16:34:06] bj...@php.net Automatic comment from SVN on behalf of bjori Revision: http://svn.php.net/viewvc/?view=revision&revision=308328 Log: bfn for #54016 [2011-02-14 16:32:05] bj...@php.net Automatic comment from SVN on behalf of bjori Revision: http://svn.php.net/viewvc/?view=revision&revision=308327 Log: Bug#54016 (finfo_file() Cannot determine filetype in archives) [2011-02-14 16:21:14] bj...@php.net The following patch has been added/updated: Patch Name: finfo.patch Revision: 1297696874 URL: http://bugs.php.net/patch-display.php?bug=54016&patch=finfo.patch&revision=1297696874 [2011-02-14 16:20:55] bj...@php.net Description: finfo_file() does not support stream wrappers, such as zip://, even though it has stream context option :( Test script: --- http://bugs.php.net/bug.php?id=54016&edit=1
[PHP-BUG] Bug #54422 [NEW]: possibly a bug in file_exists() found
From:
Operating system: linux
PHP version: 5.3.6
Package: Filesystem function related
Bug Type: Bug
Bug description:possibly a bug in file_exists() found
Description:
When using built-in function "file_exists" in 5.3.5 I encountered a trouble
of locating one file, which had apostrophe in its' name.
$filename = "America's Army.png";
if ( file_exists($filename) ) echo "found it";
else echo "bug";
After backslashing the single quote ("America\'s Army.png"), I managed to
get things working.
I considered this as bug since it has nothing o do with DB/HTML
backslashing, and also took me a few hours to find out what the problem
was.
Test script:
---
// To test, copy a single file called "America's Army.png" to the initial
dir
$filename = "America's Army.png";
if ( file_exists($filename) ) echo "found it";
else echo "bug";
Expected result:
found it
Actual result:
--
bug
--
Edit bug report at http://bugs.php.net/bug.php?id=54422&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54422&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54422&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54422&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54422&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54422&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54422&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54422&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54422&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54422&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54422&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54422&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54422&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54422&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54422&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54422&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54422&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54422&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54422&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54422&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54422&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54422&r=mysqlcfg
[PHP-BUG] Bug #54423 [NEW]: classes from dl()'ed extensions are not destroyed
From: Operating system: PHP version: 5.3SVN-2011-03-30 (SVN) Package: Scripting Engine problem Bug Type: Bug Bug description:classes from dl()'ed extensions are not destroyed Description: If an extension loaded with dl() declares any clasess, these classes are not destroyed along with the module and it's other resources. That causes crashes when using delayed early binding, though that's not a requirement, see reproduce case below. Test script: --- Reproduce case is quite intricate: start ONE child process of any PHP SAPI (except CLI/CGI/embed, of course) execute this code: ) $o = new ; ?> then comment out the dl() and execute it again. The class is still present, but it's handler pointers are invalid, therefore PHP will crash with a similar backtrace: Program received signal SIGSEGV, Segmentation fault. 0xb6e17da0 in ?? () (gdb) bt #0 0xb6e17da0 in ?? () #1 0x081cc629 in _object_and_properties_init (arg=0x83deae8, class_type=0x8455380, properties=0x0) at /local/dev/php/PHP_5_3/Zend/zend_API.c:1088 #2 0x081cc730 in _object_init_ex (arg=0x83deae8, class_type=0x8455380) at /local/dev/php/PHP_5_3/Zend/zend_API.c:1096 #3 0x081ee86d in ZEND_NEW_SPEC_HANDLER (execute_data=0x8411d80) at /local/dev/php/PHP_5_3/Zend/zend_vm_execute.h:476 #4 0x081eb4f9 in execute (op_array=0x83dd3f4) at /local/dev/php/PHP_5_3/Zend/zend_vm_execute.h:107 #5 0x081cab82 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /local/dev/php/PHP_5_3/Zend/zend.c:1194 #6 0x08179b90 in php_execute_script (primary_file=0xbfda0cb0) at /local/dev/php/PHP_5_3/main/main.c:2268 #7 0x0825a53d in main (argc=1, argv=0xbfda0e04) at /local/dev/php/PHP_5_3/sapi/fpm/fpm/fpm_main.c:1882 (gdb) f 1 #1 0x081cc629 in _object_and_properties_init (arg=0x83deae8, class_type=0x8455380, properties=0x0) at /local/dev/php/PHP_5_3/Zend/zend_API.c:1088 1088Z_OBJVAL_P(arg) = class_type->create_object(class_type TSRMLS_CC); (gdb) p class_type->create_object $1 = (zend_object_value (*)(zend_class_entry *)) 0xb6e17da0 (gdb) p *class_type->create_object Cannot access memory at address 0xb6e17da0 -- Edit bug report at http://bugs.php.net/bug.php?id=54423&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54423&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54423&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54423&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54423&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54423&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54423&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54423&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54423&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54423&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54423&r=support Expected behavior: http://bugs.php.net/fix.php?id=54423&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54423&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54423&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54423&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54423&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54423&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54423&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54423&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54423&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54423&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54423&r=mysqlcfg
[PHP-BUG] Bug #54424 [NEW]: failed assert with ASSERT_BAIL exits with return code == 0
From: Operating system: linux PHP version: 5.3.6 Package: *General Issues Bug Type: Bug Bug description:failed assert with ASSERT_BAIL exits with return code == 0 Description: Failed assertions should be signaled by non-zero return code from the script as they are errors. Test script: --- $ cat example.php $ php example.php PHP Warning: assert(): Assertion failed in /home/lopuszanski/projects/NK-2/tests/php/example.php on line 3 $ echo $? 0 Expected result: echo $? should display some nonzero return code Actual result: -- 0 -- Edit bug report at http://bugs.php.net/bug.php?id=54424&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54424&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54424&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54424&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54424&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54424&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54424&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54424&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54424&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54424&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54424&r=support Expected behavior: http://bugs.php.net/fix.php?id=54424&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54424&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54424&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54424&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54424&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54424&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54424&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54424&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54424&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54424&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54424&r=mysqlcfg
Bug #54403 [Com]: FILTER_VALIDATE_EMAIL
Edit report at http://bugs.php.net/bug.php?id=54403&edit=1
ID: 54403
Comment by: carsten_sttgt at gmx dot de
Reported by:mariomaresca at hotmail dot it
Summary:FILTER_VALIDATE_EMAIL
Status: Bogus
Type: Bug
Package:Filter related
Operating System: windows 7
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
@aharvey
> That's a valid e-mail address: RFC 2822
According to RFC 2822 and this topic FILTER_VALIDATE_EMAIL is working
wrong ("ma...@mail.com" isn't a valid e-mail address, see the answer
from Tomas).
BTW:
FILTER_VALIDATE_EMAIL is working according to RFC2822? In the manual I
can't read which rules are used for validating e-mails.
Previous Comments:
[2011-03-29 16:28:49] dtajchre...@php.net
Once the expected/correct behavior is agreed upon, we should also add a
test case
for this. filter's behavior has been inconsistent across the last 10+
releases.
[2011-03-29 15:18:29] tomas dot brastavicius at quantum dot lt
It is not correct. Address contains no characters other than atext
characters or "." surrounded by atext.
dot-atom = [CFWS] dot-atom-text [CFWS]
dot-atom-text = 1*atext *("." 1*atext)
Reference, http://tools.ietf.org/html/rfc2822#section-3.2.4
[2011-03-29 11:41:10] ahar...@php.net
That's a valid e-mail address: RFC 2822 only requires the local part to
be a valid dot-atom, and dot-atom elements may end with a period.
[2011-03-27 19:29:56] mariomaresca at hotmail dot it
Description:
---
>From manual page: http://www.php.net/function.filter-var#Description
---
filter_var with FILTER_VALIDATE_EMAIL takes as good this malformed
email:
"ma...@mail.com"
Test script:
---
$email='ma...@mail.com';
if (filter_var($email, FILTER_VALIDATE_EMAIL))
echo '$email is good';
else
echo '$email is bad';
Expected result:
$email is bad
Actual result:
--
$email is good
--
Edit this bug report at http://bugs.php.net/bug.php?id=54403&edit=1
[PHP-BUG] Bug #54425 [NEW]: Loading PHP extension fails due to incorrrect ini directory path
From: Operating system: Windows XP PHP version: 5.3.6 Package: Windows Installer Bug Type: Bug Bug description:Loading PHP extension fails due to incorrrect ini directory path Description: Steps: 1. Install Apache (used 2.2.17 from Apache Lounge, but shouldn't be specific). 2. Install PHP 5.3.6 TS VC9 as Apache 2.2 module. Expected result: Expected result: PHPIniDir "C:/Program Files/PHP/" LoadModule php5_module "C:/Program Files/PHP/php5apache2_2.dll" Actual result: -- PHPIniDir "C:\Program Files\PHP\" LoadModule php5_module "C:\Program Files\PHP\php5apache2_2.dll" As a result some (all?) PHP extensions cannot be loaded by Apache. Yes, this is not entirely fault of PHP, but I'm almost sure it used to be fine in previous versions. -- Edit bug report at http://bugs.php.net/bug.php?id=54425&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54425&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54425&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54425&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54425&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54425&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54425&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54425&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54425&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54425&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54425&r=support Expected behavior: http://bugs.php.net/fix.php?id=54425&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54425&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54425&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54425&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54425&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54425&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54425&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54425&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54425&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54425&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54425&r=mysqlcfg
[PHP-BUG] Bug #54426 [NEW]: Wrong NULL checks
From: Operating system: All PHP version: 5.3.6 Package: InterBase related Bug Type: Bug Bug description:Wrong NULL checks Description: ibase_query.c contains on line 676 checks for NULL. But this is wrong, as the value could be provided in trigger etc. Simply removing this check should be enough and everything will be working fine. -- Edit bug report at http://bugs.php.net/bug.php?id=54426&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54426&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54426&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54426&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54426&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54426&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54426&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54426&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54426&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54426&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54426&r=support Expected behavior: http://bugs.php.net/fix.php?id=54426&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54426&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54426&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54426&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54426&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54426&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54426&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54426&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54426&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54426&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54426&r=mysqlcfg
Req #45002 [Com]: __get() and __set() don't work for static variable calls
Edit report at http://bugs.php.net/bug.php?id=45002&edit=1 ID: 45002 Comment by: marious dot alex at gmail dot com Reported by:jb2386 at hotmail dot com Summary:__get() and __set() don't work for static variable calls Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: Any PHP Version:5.2.6 Block user comment: N Private report: N New Comment: This would be a really useful feature that I have been wishing for, for at least two years. How come this has not been implemented when it is such a simple feature that has also been requested since 2008? Previous Comments: [2010-06-25 12:22:21] temporary dot hole at googlemail dot com I have an idea to use this for a static registry class, would be really useful for keeping 'application-wide' data out of global variables. I have no idea how to apply this patch, is it possible to use the above mentioned .diff on PHP 5.3.1 ? [2010-05-14 09:13:41] vincentbab at gmail dot com I would really apreciate this feature too [2009-09-24 10:23:05] peter dot rother at gmail dot com 'Twould be seriously nice to have this featureâ¦please let us know if anything can be done soon. [2009-08-01 15:25:58] atrauzzi at gmail dot com I'd have to say I'm waiting on this feature as well. Is there a snapshot I could be using to test it out? [2009-07-30 21:21:58] some at email dot com When to expect resolving this bug 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/bug.php?id=45002 -- Edit this bug report at http://bugs.php.net/bug.php?id=45002&edit=1
Bug #44989 [Csd]: 64bit Oracle RPMs still not supported by pdo-oci
Edit report at http://bugs.php.net/bug.php?id=44989&edit=1 ID: 44989 Updated by: s...@php.net Reported by:stevec at engr dot oregonstate dot edu Summary:64bit Oracle RPMs still not supported by pdo-oci Status: Closed Type: Bug Package:PDO related Operating System: Linux PHP Version:5.2.6 Assigned To:sixd Block user comment: N Private report: N New Comment: With Oracle Instant Client 11.2 RPMs use: ./configure --with-pdo-oci=instantclient,/usr,11.2 or ./configure --with-pdo-oci=shared,instantclient,/usr,11.2 i.e. only use two components of the version number. Previous Comments: [2011-03-29 20:41:26] fel...@php.net 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/. Thank you for the report, and for helping us make PHP better. Thanks for the patch! [2011-03-29 20:40:23] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revision&revision=309818 Log: - Fixed bug #44989 (64bit Oracle RPMs still not supported by pdo-oci) patch by: jbnance at tresgeek dot net [2010-08-16 23:12:49] jbnance at tresgeek dot net Bug still exists in 5.3.3. Patch uploaded. [2010-08-04 01:03:29] jbnance at tresgeek dot net Patch attached for config.m4. Notes for end users, in order to use this you have to rebuild configure (buildconf --force after applying the patch). After applying and rebuilding, the following should work: ./configure --with-pdo-oci=instantclient,/usr,10.2.0.4 or ./configure --with-pdo-oci=shared,instantclient,/usr,10.2.0.4 Note that this is different from the non-PDO OCI configure option: --with-oci8=instantclient,/usr/lib/oracle/10.2.0.4/client64/lib or --with-oci8=shared,instantclient,/usr/lib/oracle/10.2.0.4/client64/lib (the version is a parameter in the PDO OCI option). [2009-05-03 01:00:13] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". 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/bug.php?id=44989 -- Edit this bug report at http://bugs.php.net/bug.php?id=44989&edit=1
Bug #39312 [Fbk->Dup]: Cannot install PDO_OCI
Edit report at http://bugs.php.net/bug.php?id=39312&edit=1 ID: 39312 Updated by: s...@php.net Reported by:andrew dot nagy at villanova dot edu Summary:Cannot install PDO_OCI -Status: Feedback +Status: Duplicate Type: Bug Package:PDO related Operating System: Linux PHP Version:5.2.9 Assigned To:sixd Block user comment: N Private report: N New Comment: There seem to be a number of overlapping issues in this bug some of which have been fixed by now. See http://bugs.php.net/bug.php?id=44989 Note the use with RPMs only requires the top level path /usr and the version number should either be 10.2.0.4 or 11.2 (not 11.2.0.2) depending on which Instant Client you use. Also support for 11.2 added in http://svn.php.net/viewvc?view=revision&revision=294487 The only obviously outstanding issue is to change from hardcoded .so given in the patch inline by: [2009-01-29 10:37 UTC] michael-ring at t-online dot de Previous Comments: [2010-06-24 09:30:34] petri dot mahanen at brainalliance dot com The snapshot will still not compile on OS X as the patch of [2009-01-29 09:37 UTC] michael-ring at t-online dot de has not been applied. [2010-03-25 12:12:34] ka...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2010-03-16 20:54:32] jbrauer at llu dot edu I got it to build on Redhat using the instantclient RPM. Here's what I did. manually added the following to config.m4 to allow for Oracle instant client 11.1 (stolen from matts at iastate above) @@ -7,6 +7,8 @@ if test -s "$PDO_OCI_DIR/orainst/unix.rgs"; then PDO_OCI_VERSION=`grep '"ocommon"' $PDO_OCI_DIR/orainst/unix.rgs | sed 's/[ ][ ]*/:/g' | cut -d: -f 6 | cut -c 2-4` test -z "$PDO_OCI_VERSION" && PDO_OCI_VERSION=7.3 + elif test -f $PDO_OCI_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.11.1; then +PDO_OCI_VERSION=11.1 elif test -f $PDO_OCI_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.10.1; then PDO_OCI_VERSION=10.1 elif test -f $PDO_OCI_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.9.0; then AND @@ -119,6 +126,9 @@ 10.2) PHP_ADD_LIBRARY(clntsh, 1, PDO_OCI_SHARED_LIBADD) ;; +11.1) + dnl PHP_ADD_LIBRARY(clntsh, 1, PDO_OCI_SHARED_LIBADD) + ;; *) AC_MSG_ERROR(Unsupported Oracle version! $PDO_OCI_VERSION) ;; if you have instant client of lower version its not needed. Then I re phpize 'd it. and ran configure: (esimard at mediagrif dot com)'s strace showed me the only dir I needed was /usr ./configure --with-pdo-oci=instantclient,/usr,11.1.0.1 configure, make and make install completed successfully [2009-09-16 21:15:51] matts at iastate dot edu Since the above messed up the formatting, I'll keep a copy of the patch here for the meantime: http://booster.agron.iastate.edu/mattsteven/oci_patch_jaunty.patch [2009-09-16 21:13:02] matts at iastate dot edu Here is a patch which will let you build the pdo_oci lib with the instant client on debian or ubuntu systems. Save the contents to oci_patch.txt, and then run it against your config.m4 file like so: cd PDO_OCI-1.0 && patch -p0 < /path/to/oci_patch.txt = ### Eclipse Workspace Patch 1.0 #P pdo_oci Index: config.m4 === --- config.m4 (revision 141) +++ config.m4 (working copy) @@ -7,6 +7,8 @@ if test -s "$PDO_OCI_DIR/orainst/unix.rgs"; then PDO_OCI_VERSION=`grep '"ocommon"' $PDO_OCI_DIR/orainst/unix.rgs | sed 's/[ ][ ]*/:/g' | cut -d: -f 6 | cut -c 2-4` test -z "$PDO_OCI_VERSION" && PDO_OCI_VERSION=7.3 + elif test -f $PDO_OCI_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.11.1; then +PDO_OCI_VERSION=11.1 elif test -f $PDO_OCI_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.10.1; then PDO_OCI_VERSION=10.1 elif test -f $PDO_OCI_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.9.0; then @@ -57,14 +59,19 @@ AC_MSG_CHECKING([for oci.h]) if test -f $PDO_OCI_IC_PREFIX/include/oracle/$PDO_OCI_IC_VERS/client/oci.h ; then PHP_ADD_INCLUDE($PDO_OCI_IC_PREFIX/include/oracle/$PDO_OCI_IC_VERS/client) + PDO_OCI_LIB_DIR="$PDO_OCI_IC_PREFIX/lib/oracle/$PDO_OCI_IC_VERS/client/lib" AC_MSG_RESULT($PDO_OCI_IC_PREFIX/include/oracle/$PDO_OCI_IC_VERS/client) elif test -f $PDO_OCI_IC_PREFIX/lib/oracle/$PDO_OCI_IC_VERS/client/include/oci.h ; then PHP_ADD_INCLUDE($PDO_OCI_IC_PREFIX/lib/oracle/$PDO_OCI_IC_VERS/
Bug #39312 [Dup->ReO]: Cannot install PDO_OCI
Edit report at http://bugs.php.net/bug.php?id=39312&edit=1 ID: 39312 Updated by: s...@php.net Reported by:andrew dot nagy at villanova dot edu Summary:Cannot install PDO_OCI -Status: Duplicate +Status: Re-Opened Type: Bug Package:PDO related Operating System: Linux PHP Version:5.2.9 Assigned To:sixd Block user comment: N Private report: N Previous Comments: [2011-03-30 19:44:20] s...@php.net There seem to be a number of overlapping issues in this bug some of which have been fixed by now. See http://bugs.php.net/bug.php?id=44989 Note the use with RPMs only requires the top level path /usr and the version number should either be 10.2.0.4 or 11.2 (not 11.2.0.2) depending on which Instant Client you use. Also support for 11.2 added in http://svn.php.net/viewvc?view=revision&revision=294487 The only obviously outstanding issue is to change from hardcoded .so given in the patch inline by: [2009-01-29 10:37 UTC] michael-ring at t-online dot de [2010-06-24 09:30:34] petri dot mahanen at brainalliance dot com The snapshot will still not compile on OS X as the patch of [2009-01-29 09:37 UTC] michael-ring at t-online dot de has not been applied. [2010-03-25 12:12:34] ka...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2010-03-16 20:54:32] jbrauer at llu dot edu I got it to build on Redhat using the instantclient RPM. Here's what I did. manually added the following to config.m4 to allow for Oracle instant client 11.1 (stolen from matts at iastate above) @@ -7,6 +7,8 @@ if test -s "$PDO_OCI_DIR/orainst/unix.rgs"; then PDO_OCI_VERSION=`grep '"ocommon"' $PDO_OCI_DIR/orainst/unix.rgs | sed 's/[ ][ ]*/:/g' | cut -d: -f 6 | cut -c 2-4` test -z "$PDO_OCI_VERSION" && PDO_OCI_VERSION=7.3 + elif test -f $PDO_OCI_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.11.1; then +PDO_OCI_VERSION=11.1 elif test -f $PDO_OCI_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.10.1; then PDO_OCI_VERSION=10.1 elif test -f $PDO_OCI_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.9.0; then AND @@ -119,6 +126,9 @@ 10.2) PHP_ADD_LIBRARY(clntsh, 1, PDO_OCI_SHARED_LIBADD) ;; +11.1) + dnl PHP_ADD_LIBRARY(clntsh, 1, PDO_OCI_SHARED_LIBADD) + ;; *) AC_MSG_ERROR(Unsupported Oracle version! $PDO_OCI_VERSION) ;; if you have instant client of lower version its not needed. Then I re phpize 'd it. and ran configure: (esimard at mediagrif dot com)'s strace showed me the only dir I needed was /usr ./configure --with-pdo-oci=instantclient,/usr,11.1.0.1 configure, make and make install completed successfully [2009-09-16 21:15:51] matts at iastate dot edu Since the above messed up the formatting, I'll keep a copy of the patch here for the meantime: http://booster.agron.iastate.edu/mattsteven/oci_patch_jaunty.patch The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=39312 -- Edit this bug report at http://bugs.php.net/bug.php?id=39312&edit=1
Bug #26565 [Com]: strtotime('this month') resolving to the wrong month?
Edit report at http://bugs.php.net/bug.php?id=26565&edit=1
ID: 26565
Comment by: fortizma at gmail dot com
Reported by:michaelw at darkhorse dot com
Summary:strtotime('this month') resolving to the wrong
month?
Status: Closed
Type: Bug
Package:Date/time related
Operating System: Mac OS X 10.2.x
PHP Version:4.3.4
Block user comment: N
Private report: N
New Comment:
Based on the current date which is march 30, 2011.
if I try echo date('Y-m-d', strtotime('-1 months')); I would expect
2011-02-28,
but what I'm getting is 2011-03-02.
Do this occur due to 2011 is not a leap year?
Previous Comments:
[2003-12-10 09:06:48] sni...@php.net
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2003-12-10 05:57:44] m...@php.net
More to the point, "next" is specifically equated to "2" (or "+2") in
the documentation referenced by the strtotime() manual page, so your
expectation for "next month" is simply wrong.
However, "this" is also specifically equated to a "zero-valued
displacement ... preferred in date strings like `this thursday'" (which
doesn't sound very "fuzzy" to me), so the behaviour of "this month" in
your example is, at the least, questionable. On this basis, I'm
re-opening this bug (with a revised summary) so a developer who knows
their way round strtotime() can take another look.
[2003-12-09 14:37:06] sni...@php.net
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
And this is expected behaviour. (this, next, etc. are FUZZY, rtfm)
[2003-12-09 13:09:41] michaelw at darkhorse dot com
Description:
strtotime adds an extra month when using the phrase
"this month" or "next month". Using '+1 months' or '+0
months' works fine, though.
And, no, I'm not adding a month to 'Jan. 30'.
Reproduce code:
---
echo date('Y-m-d', strtotime('last month'));
echo date('Y-m-d', strtotime('this month'));
echo date('Y-m-d', strtotime('next month'));
echo date('Y-m-d', strtotime('-1 months'));
echo date('Y-m-d', strtotime('+0 months'));
echo date('Y-m-d', strtotime('+1 months'));
Expected result:
2003-11-09
2003-12-09
2004-01-09
2003-11-09
2003-12-09
2004-01-09
Actual result:
--
2003-11-09
2004-01-09
2004-02-09
2003-11-09
2003-12-09
2004-01-09
--
Edit this bug report at http://bugs.php.net/bug.php?id=26565&edit=1
Bug #26565 [Csd]: strtotime('this month') resolving to the wrong month?
Edit report at http://bugs.php.net/bug.php?id=26565&edit=1
ID: 26565
Updated by: der...@php.net
Reported by:michaelw at darkhorse dot com
Summary:strtotime('this month') resolving to the wrong
month?
Status: Closed
Type: Bug
Package:Date/time related
Operating System: Mac OS X 10.2.x
PHP Version:4.3.4
-Assigned To:
+Assigned To:derick
Block user comment: N
Private report: N
New Comment:
http://derickrethans.nl/obtaining-the-next-month-in-php.html
Previous Comments:
[2011-03-30 19:45:35] fortizma at gmail dot com
Based on the current date which is march 30, 2011.
if I try echo date('Y-m-d', strtotime('-1 months')); I would expect
2011-02-28,
but what I'm getting is 2011-03-02.
Do this occur due to 2011 is not a leap year?
[2003-12-10 09:06:48] sni...@php.net
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2003-12-10 05:57:44] m...@php.net
More to the point, "next" is specifically equated to "2" (or "+2") in
the documentation referenced by the strtotime() manual page, so your
expectation for "next month" is simply wrong.
However, "this" is also specifically equated to a "zero-valued
displacement ... preferred in date strings like `this thursday'" (which
doesn't sound very "fuzzy" to me), so the behaviour of "this month" in
your example is, at the least, questionable. On this basis, I'm
re-opening this bug (with a revised summary) so a developer who knows
their way round strtotime() can take another look.
[2003-12-09 14:37:06] sni...@php.net
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
And this is expected behaviour. (this, next, etc. are FUZZY, rtfm)
[2003-12-09 13:09:41] michaelw at darkhorse dot com
Description:
strtotime adds an extra month when using the phrase
"this month" or "next month". Using '+1 months' or '+0
months' works fine, though.
And, no, I'm not adding a month to 'Jan. 30'.
Reproduce code:
---
echo date('Y-m-d', strtotime('last month'));
echo date('Y-m-d', strtotime('this month'));
echo date('Y-m-d', strtotime('next month'));
echo date('Y-m-d', strtotime('-1 months'));
echo date('Y-m-d', strtotime('+0 months'));
echo date('Y-m-d', strtotime('+1 months'));
Expected result:
2003-11-09
2003-12-09
2004-01-09
2003-11-09
2003-12-09
2004-01-09
Actual result:
--
2003-11-09
2004-01-09
2004-02-09
2003-11-09
2003-12-09
2004-01-09
--
Edit this bug report at http://bugs.php.net/bug.php?id=26565&edit=1
Bug #26565 [Com]: strtotime('this month') resolving to the wrong month?
Edit report at http://bugs.php.net/bug.php?id=26565&edit=1
ID: 26565
Comment by: fortizma at gmail dot com
Reported by:michaelw at darkhorse dot com
Summary:strtotime('this month') resolving to the wrong
month?
Status: Closed
Type: Bug
Package:Date/time related
Operating System: Mac OS X 10.2.x
PHP Version:4.3.4
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
Derik, thanks for your reply, but in my last reply, I'm talking about
last month,
no next month.
Thanks in advance.
Previous Comments:
[2011-03-30 19:48:40] der...@php.net
http://derickrethans.nl/obtaining-the-next-month-in-php.html
[2011-03-30 19:45:35] fortizma at gmail dot com
Based on the current date which is march 30, 2011.
if I try echo date('Y-m-d', strtotime('-1 months')); I would expect
2011-02-28,
but what I'm getting is 2011-03-02.
Do this occur due to 2011 is not a leap year?
[2003-12-10 09:06:48] sni...@php.net
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2003-12-10 05:57:44] m...@php.net
More to the point, "next" is specifically equated to "2" (or "+2") in
the documentation referenced by the strtotime() manual page, so your
expectation for "next month" is simply wrong.
However, "this" is also specifically equated to a "zero-valued
displacement ... preferred in date strings like `this thursday'" (which
doesn't sound very "fuzzy" to me), so the behaviour of "this month" in
your example is, at the least, questionable. On this basis, I'm
re-opening this bug (with a revised summary) so a developer who knows
their way round strtotime() can take another look.
[2003-12-09 14:37:06] sni...@php.net
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
And this is expected behaviour. (this, next, etc. are FUZZY, rtfm)
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/bug.php?id=26565
--
Edit this bug report at http://bugs.php.net/bug.php?id=26565&edit=1
Bug #26565 [Com]: strtotime('this month') resolving to the wrong month?
Edit report at http://bugs.php.net/bug.php?id=26565&edit=1
ID: 26565
Comment by: rbredlau at broadlux dot com
Reported by:michaelw at darkhorse dot com
Summary:strtotime('this month') resolving to the wrong
month?
Status: Closed
Type: Bug
Package:Date/time related
Operating System: Mac OS X 10.2.x
PHP Version:4.3.4
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
I am having the exact same error as fortizma.
http://derickrethans.nl/obtaining-the-next-month-in-php.html
[2011-03-30 19:45:35] fortizma at gmail dot com
Based on the current date which is march 30, 2011.
if I try echo date('Y-m-d', strtotime('-1 months')); I would expect
2011-02-28,
but what I'm getting is 2011-03-02.
Do this occur due to 2011 is not a leap year?
[2003-12-10 09:06:48] sni...@php.net
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2003-12-10 05:57:44] m...@php.net
More to the point, "next" is specifically equated to "2" (or "+2") in
the documentation referenced by the strtotime() manual page, so your
expectation for "next month" is simply wrong.
However, "this" is also specifically equated to a "zero-valued
displacement ... preferred in date strings like `this thursday'" (which
doesn't sound very "fuzzy" to me), so the behaviour of "this month" in
your example is, at the least, questionable. On this basis, I'm
re-opening this bug (with a revised summary) so a developer who knows
their way round strtotime() can take another look.
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/bug.php?id=26565
--
Edit this bug report at http://bugs.php.net/bug.php?id=26565&edit=1
Bug #26565 [Csd]: strtotime('this month') resolving to the wrong month?
Edit report at http://bugs.php.net/bug.php?id=26565&edit=1
ID: 26565
Updated by: ras...@php.net
Reported by:michaelw at darkhorse dot com
Summary:strtotime('this month') resolving to the wrong
month?
Status: Closed
Type: Bug
Package:Date/time related
Operating System: Mac OS X 10.2.x
PHP Version:4.3.4
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
To the people adding comments about +-1 month here. This really isn't a
bug. Read the link Derick provided:
http://derickrethans.nl/obtaining-the-next-month-in-php.html
It doesn't matter if you are going ahead 1 month or back 1 month. The
logic is the same. It tries to find Feb.30 which doesn't exist, so
instead of walking backwards to Feb.28 it assumes you meant 2 days after
Feb.28 which is obviously in March. Like I said in the comments at that
link, for better or worse, this is the UNIX convention for time
manipulation. Most UNIX tools will behave exactly like this. In order to
do this correctly, you should be specifying a day in the month as Derick
suggests in that post.
Previous Comments:
[2011-03-30 22:01:12] rbredlau at broadlux dot com
I am having the exact same error as fortizma.
http://derickrethans.nl/obtaining-the-next-month-in-php.html
[2011-03-30 19:45:35] fortizma at gmail dot com
Based on the current date which is march 30, 2011.
if I try echo date('Y-m-d', strtotime('-1 months')); I would expect
2011-02-28,
but what I'm getting is 2011-03-02.
Do this occur due to 2011 is not a leap year?
[2003-12-10 09:06:48] sni...@php.net
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=26565
--
Edit this bug report at http://bugs.php.net/bug.php?id=26565&edit=1
Bug #26565 [Com]: strtotime('this month') resolving to the wrong month?
Edit report at http://bugs.php.net/bug.php?id=26565&edit=1
ID: 26565
Comment by: fortizma at gmail dot com
Reported by:michaelw at darkhorse dot com
Summary:strtotime('this month') resolving to the wrong
month?
Status: Closed
Type: Bug
Package:Date/time related
Operating System: Mac OS X 10.2.x
PHP Version:4.3.4
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
Ok Rasmus thanks for your reply.
However in my opinion is not a correct behavioural. So if I ask today
march, 30
for the "last month" the function should return feb 28. The function
should not
assumes that I meant 2 days after Feb.28, when I'm just passing as param
lastmonth.
Anyways, in my opinión the function is not working properly, because if
I'm
asking about lastmonth the answer should not be the current month.
how you can create a function working properly, that return the correct
last
month every day in PHP 5.2.x.
Previous Comments:
[2011-03-30 22:39:23] ras...@php.net
To the people adding comments about +-1 month here. This really isn't a
bug. Read the link Derick provided:
http://derickrethans.nl/obtaining-the-next-month-in-php.html
It doesn't matter if you are going ahead 1 month or back 1 month. The
logic is the same. It tries to find Feb.30 which doesn't exist, so
instead of walking backwards to Feb.28 it assumes you meant 2 days after
Feb.28 which is obviously in March. Like I said in the comments at that
link, for better or worse, this is the UNIX convention for time
manipulation. Most UNIX tools will behave exactly like this. In order to
do this correctly, you should be specifying a day in the month as Derick
suggests in that post.
[2011-03-30 22:01:12] rbredlau at broadlux dot com
I am having the exact same error as fortizma.
http://derickrethans.nl/obtaining-the-next-month-in-php.html
[2011-03-30 19:45:35] fortizma at gmail dot com
Based on the current date which is march 30, 2011.
if I try echo date('Y-m-d', strtotime('-1 months')); I would expect
2011-02-28,
but what I'm getting is 2011-03-02.
Do this occur due to 2011 is not a leap year?
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/bug.php?id=26565
--
Edit this bug report at http://bugs.php.net/bug.php?id=26565&edit=1
Bug #54415 [Opn]: php-cgi: linker error with Easysoft unixODBC integration
Edit report at http://bugs.php.net/bug.php?id=54415&edit=1 ID: 54415 User updated by:mark dot dalton at mail dot house dot gov Reported by:mark dot dalton at mail dot house dot gov Summary:php-cgi: linker error with Easysoft unixODBC integration Status: Open Type: Bug Package:Compile Failure Operating System: Solaris 10 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: You are going to love this. I pulled down the 5.3.6 version of PHP, extracted it, and built it fine. Go figure⦠Please close this bug report. Previous Comments: [2011-03-29 00:10:02] mark dot dalton at mail dot house dot gov Corrected small spelling error in 'Summary' field. [2011-03-29 00:05:44] mark dot dalton at mail dot house dot gov Description: This problem is with building PHP 5.3.5. I'm using SolarisStudio compiler and /usr/ccs/bin/ld as the linker. Input to configure: ./configure \ --prefix=/usr2/web/home/plugins/php-5.3.5 \ --bindir=/usr2/web/home/plugins/php-5.3.5/bin \ --libdir=/usr2/web/home/plugins/php-5.3.5/lib \ --libexecdir=/usr2/web/home/plugins/php-5.3.5/libexec \ --enable-debug \ --with-gnu-ld \ --oldincludedir=/usr/include \ --with-unixODBC=/usr/local/easysoft/unixODBC \ --enable-calendar Very tail-end nippet from 'make' (build) run: Undefined first referenced symbol in file _php_glob_stream_get_path ext/spl/spl_directory.o _php_glob_stream_get_count ext/spl/spl_directory.o php_glob_stream_ops ext/spl/spl_directory.o php_glob_stream_wrapper ext/standard/basic_functions.o ld: fatal: Symbol referencing errors. No output written to sapi/cgi/php-cgi *** Error code 2 make: Fatal error: Command failed for target `sapi/cgi/php-cgi' This error is not generated for the CLI PHP module nor does it occur if '--with-unixODBC=/usr/local/easysoft/unixODBC' is left out of the configure run. I tried to force inclusion of the required 'php_glob_stream' references by adding in '#include streams/php_stream_glob_wrapper.h' into the 2 C modules that were involved but that made no difference at all. Test script: --- Tail-end nippet from 'make' (build) run (lengthy): cc -m64 -I/usr/include -g ext/date/php_date.o ext/date/lib/astro.o ext/date/lib/dow.o ext/date/lib/parse_date.o ext/date/lib/parse_tz.o ext/date/lib/timelib.o ext/date/lib/tm2unixtime.o ext/date/lib/unixtime2tm.o ext/date/lib/parse_iso_intervals.o ext/date/lib/interval.o ext/ereg/ereg.o ext/ereg/regex/regcomp.o ext/ereg/regex/regexec.o ext/ereg/regex/regerror.o ext/ereg/regex/regfree.o ext/libxml/libxml.o ext/pcre/pcrelib/pcre_chartables.o ext/pcre/pcrelib/pcre_ucd.o ext/pcre/pcrelib/pcre_compile.o ext/pcre/pcrelib/pcre_config.o ext/pcre/pcrelib/pcre_exec.o ext/pcre/pcrelib/pcre_fullinfo.o ext/pcre/pcrelib/pcre_get.o ext/pcre/pcrelib/pcre_globals.o ext/pcre/pcrelib/pcre_info.o ext/pcre/pcrelib/pcre_maketables.o ext/pcre/pcrelib/pcre_newline.o ext/pcre/pcrelib/pcre_ord2utf8.o ext/pcre/pcrelib/pcre_refcount.o ext/pcre/pcrelib/pcre_study.o ext/pcre/pcrelib/pcre_tables.o ext/pcre/pcrelib/pcre_try_flipped.o ext/pcre/pcrelib/pcre_valid_utf8.o ext/pcre/pcrelib/pcre_version.o ext/pcre/pcrelib/pcre_xclass.o ext/pcre/php_pcre.o ext/sqlite3/sqlite3.o ext/sqlite3/libsqlite/sqlite3.o ext/calendar/calendar.o ext/calendar/dow.o ext/calendar/french.o ext/calendar/gregor.o ext/calendar/jewish.o ext/calendar/julian.o ext/calendar/easter.o ext/calendar/cal_unix.o ext/ctype/ctype.o ext/dom/php_dom.o ext/dom/attr.o ext/dom/document.o ext/dom/domerrorhandler.o ext/dom/domstringlist.o ext/dom/domexception.o ext/dom/namelist.o ext/dom/processinginstruction.o ext/dom/cdatasection.o ext/dom/documentfragment.o ext/dom/domimplementation.o ext/dom/element.o ext/dom/node.o ext/dom/string_extend.o ext/dom/characterdata.o ext/dom/documenttype.o ext/dom/domimplementationlist.o ext/dom/entity.o ext/dom/nodelist.o ext/dom/text.o ext/dom/comment.o ext/dom/domconfiguration.o ext/dom/domimplementationsource.o ext/dom/entityreference.o ext/dom/notation.o ext/dom/xpath.o ext/dom/dom_iterators.o ext/dom/typeinfo.o ext/dom/domerror.o ext/dom/domlocator.o ext/dom/namednodemap.o ext/dom/userdatahandler.o ext/fileinfo/fileinfo.o ext/fileinfo/libmagic/apprentice.o ext/fileinfo/libmagic/apptype.o ext/fileinfo/libmagic/ascmagic.o ext/fileinfo/libmagic/cdf.o ext/fileinfo/libmagic/cdf_time.o ext/fileinfo/libmagic/compress.o ext/fileinfo/libmagic/encoding.o ext/fileinfo/libmagic/fsmagic.o ext/fileinfo/libmagic/funcs.o ext/fileinfo/libmagic/is_tar.o ext/fileinfo/libmagic/magic.o ext/fileinfo/libmagic/print.o ext/fileinfo/libmagic/readcdf.o ext/fileinfo/libmagic/readelf.
Bug #54415 [Opn->Bgs]: php-cgi: linker error with Easysoft unixODBC integration
Edit report at http://bugs.php.net/bug.php?id=54415&edit=1 ID: 54415 Updated by: fel...@php.net Reported by:mark dot dalton at mail dot house dot gov Summary:php-cgi: linker error with Easysoft unixODBC integration -Status: Open +Status: Bogus Type: Bug Package:Compile Failure Operating System: Solaris 10 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: . Previous Comments: [2011-03-30 23:39:56] mark dot dalton at mail dot house dot gov You are going to love this. I pulled down the 5.3.6 version of PHP, extracted it, and built it fine. Go figure⦠Please close this bug report. [2011-03-29 00:10:02] mark dot dalton at mail dot house dot gov Corrected small spelling error in 'Summary' field. [2011-03-29 00:05:44] mark dot dalton at mail dot house dot gov Description: This problem is with building PHP 5.3.5. I'm using SolarisStudio compiler and /usr/ccs/bin/ld as the linker. Input to configure: ./configure \ --prefix=/usr2/web/home/plugins/php-5.3.5 \ --bindir=/usr2/web/home/plugins/php-5.3.5/bin \ --libdir=/usr2/web/home/plugins/php-5.3.5/lib \ --libexecdir=/usr2/web/home/plugins/php-5.3.5/libexec \ --enable-debug \ --with-gnu-ld \ --oldincludedir=/usr/include \ --with-unixODBC=/usr/local/easysoft/unixODBC \ --enable-calendar Very tail-end nippet from 'make' (build) run: Undefined first referenced symbol in file _php_glob_stream_get_path ext/spl/spl_directory.o _php_glob_stream_get_count ext/spl/spl_directory.o php_glob_stream_ops ext/spl/spl_directory.o php_glob_stream_wrapper ext/standard/basic_functions.o ld: fatal: Symbol referencing errors. No output written to sapi/cgi/php-cgi *** Error code 2 make: Fatal error: Command failed for target `sapi/cgi/php-cgi' This error is not generated for the CLI PHP module nor does it occur if '--with-unixODBC=/usr/local/easysoft/unixODBC' is left out of the configure run. I tried to force inclusion of the required 'php_glob_stream' references by adding in '#include streams/php_stream_glob_wrapper.h' into the 2 C modules that were involved but that made no difference at all. Test script: --- Tail-end nippet from 'make' (build) run (lengthy): cc -m64 -I/usr/include -g ext/date/php_date.o ext/date/lib/astro.o ext/date/lib/dow.o ext/date/lib/parse_date.o ext/date/lib/parse_tz.o ext/date/lib/timelib.o ext/date/lib/tm2unixtime.o ext/date/lib/unixtime2tm.o ext/date/lib/parse_iso_intervals.o ext/date/lib/interval.o ext/ereg/ereg.o ext/ereg/regex/regcomp.o ext/ereg/regex/regexec.o ext/ereg/regex/regerror.o ext/ereg/regex/regfree.o ext/libxml/libxml.o ext/pcre/pcrelib/pcre_chartables.o ext/pcre/pcrelib/pcre_ucd.o ext/pcre/pcrelib/pcre_compile.o ext/pcre/pcrelib/pcre_config.o ext/pcre/pcrelib/pcre_exec.o ext/pcre/pcrelib/pcre_fullinfo.o ext/pcre/pcrelib/pcre_get.o ext/pcre/pcrelib/pcre_globals.o ext/pcre/pcrelib/pcre_info.o ext/pcre/pcrelib/pcre_maketables.o ext/pcre/pcrelib/pcre_newline.o ext/pcre/pcrelib/pcre_ord2utf8.o ext/pcre/pcrelib/pcre_refcount.o ext/pcre/pcrelib/pcre_study.o ext/pcre/pcrelib/pcre_tables.o ext/pcre/pcrelib/pcre_try_flipped.o ext/pcre/pcrelib/pcre_valid_utf8.o ext/pcre/pcrelib/pcre_version.o ext/pcre/pcrelib/pcre_xclass.o ext/pcre/php_pcre.o ext/sqlite3/sqlite3.o ext/sqlite3/libsqlite/sqlite3.o ext/calendar/calendar.o ext/calendar/dow.o ext/calendar/french.o ext/calendar/gregor.o ext/calendar/jewish.o ext/calendar/julian.o ext/calendar/easter.o ext/calendar/cal_unix.o ext/ctype/ctype.o ext/dom/php_dom.o ext/dom/attr.o ext/dom/document.o ext/dom/domerrorhandler.o ext/dom/domstringlist.o ext/dom/domexception.o ext/dom/namelist.o ext/dom/processinginstruction.o ext/dom/cdatasection.o ext/dom/documentfragment.o ext/dom/domimplementation.o ext/dom/element.o ext/dom/node.o ext/dom/string_extend.o ext/dom/characterdata.o ext/dom/documenttype.o ext/dom/domimplementationlist.o ext/dom/entity.o ext/dom/nodelist.o ext/dom/text.o ext/dom/comment.o ext/dom/domconfiguration.o ext/dom/domimplementationsource.o ext/dom/entityreference.o ext/dom/notation.o ext/dom/xpath.o ext/dom/dom_iterators.o ext/dom/typeinfo.o ext/dom/domerror.o ext/dom/domlocator.o ext/dom/namednodemap.o ext/dom/userdatahandler.o ext/fileinfo/fileinfo.o ext/fileinfo/libmagic/apprentice.o ext/fileinfo/libmagic/apptype.o ext/fileinfo/libmagic/ascmagic.o ext/fileinfo/libmagic/cdf.o ext/fileinfo/libmagic/cdf_time.o ext/fileinfo/libmagic/compress.o ext/fileinfo/libmagic/encoding.o ext/fileinfo/libmagic/fsmagic.o ext/fileinfo/libmagic/funcs.o ext/fileinfo
[PHP-BUG] Bug #54428 [NEW]: [function.imagecreatefromjpeg]: failed to open stream: HTTP request failed!
From: Operating system: Windows 7 PHP version: 5.2.17 Package: GD related Bug Type: Bug Bug description:[function.imagecreatefromjpeg]: failed to open stream: HTTP request failed! Description: --- >From manual page: http://www.php.net/function.imagecreatefromjpeg#Description --- Warning: imagecreatefromjpeg(http://truyentranhtuan.com/IMAGES/SITE IMAGES/Kimi_ni_Todoke.jpg) [function.imagecreatefromjpeg]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in /home/thegioitru/domains/thegioitruyentranh.vn/public_html/z/facebook.php on line 39 Every things are OK if the URL don't have any space, Ext: imagecreatefromjpeg(http://acb.com/PhotoImages.jpg) ==> OK But: imagecreatefromjpeg(http://acb.com/Photo Images.jpg) ==> "failed to open stream: HTTP request failed!" (have one space in "Photo" & "Images") we get images form orther host, so we can rename the suorce images, How we can get it with imagecreatefromjpeg. if this is Bug, please fix it. Thank! Test script: --- //return: OK //$up_file = "http://truyentranhtuan.com/IMAGES/MANGA/Kimi_ni_Todoke/034/01.JPG";; // return: "failed to open stream: HTTP request failed!" $up_file = "http://truyentranhtuan.com/IMAGES/SITE IMAGES/Kimi_ni_Todoke.jpg"; $new_image=imagecreatefromjpeg($up_file); Expected result: Warning: imagecreatefromjpeg(http://truyentranhtuan.com/IMAGES/SITE IMAGES/Kimi_ni_Todoke.jpg) [function.imagecreatefromjpeg]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in /home/thegioitru/domains/thegioitruyentranh.vn/public_html/z/facebook.php on line 39 -- Edit bug report at http://bugs.php.net/bug.php?id=54428&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54428&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54428&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54428&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54428&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54428&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54428&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54428&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54428&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54428&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54428&r=support Expected behavior: http://bugs.php.net/fix.php?id=54428&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54428&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54428&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54428&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54428&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54428&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54428&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54428&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54428&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54428&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54428&r=mysqlcfg
Req #28790 [Com]: Add php.ini option to disable stat cache
Edit report at http://bugs.php.net/bug.php?id=28790&edit=1
ID: 28790
Comment by: giorgio dot liscio at email dot it
Reported by:jnoll at prim dot hu
Summary:Add php.ini option to disable stat cache
Status: Assigned
Type: Feature/Change Request
Package:*General Issues
Operating System: *
PHP Version:*
Assigned To:pollita
Block user comment: N
Private report: N
New Comment:
when this will be fixed?
when lot of users work on same files is needed to clear the cache on
every call to stat functions: this is totally annoying
in plus clearing the cache every time is slower against not cache at
all
please fix :)
thank you
Previous Comments:
[2007-05-23 22:57:09] bcurry at freeshell dot org
I'd like to second the motion for an .INI-option enabling the stat
cache, defaulting to 'true.' In my case, I would certainly set this
option to 'false.'
In my humble opinion, the stat cache should either invalidate itself on
every file access and modification - or not cache entries, at all. I
depend on "file_exists" returning 'true' if a file exists, and 'false'
if not. Enabling the stat cache makes this (and similar) built-in
functions behave non-deterministically, and therefore un-reliably. The
"speed" gain of caching stat results is surely obviated by the fact
that, to obtain reliable stat results, one must call "clearstatcache"
before every call to the "file_exists" (and similar) built-in functions.
[2006-12-31 09:17:43] james at bytehosting dot com
When writing a daemon process that accesses files very often it seems
litterally stupid to cache stat on these files.
With Basic Code such as the below, the statcache adds unneccessary
overhead and actully SLOWS down the code caching & purging the cache on
EACH and EVERY revolution of code.
There MUST be an option to disable it, other than rm -rf'ing the stuff
from the src/.
Regardless if you believe its "quicker" or not is moot, for each and
every case that you give where it is quicker, I can garuntee to give you
a seperate case proving where it slows the code down.
If your not willing to add a config option, how about a runtime option?
(after all, who needs ob_implicit_flush()? its just another 'useless'
function..., same idioligy applies here). And there are PLUNTY of cases
where code such as this is required (obviously, not the exact code, its
pseudo code)
while (TRUE) {
clearstatcache();
if (file_exists("file.tmp")) {
process_stuff;
}
}
[2004-06-16 17:30:45] poll...@php.net
I'll cut ya in on a secret: The statcache is only one entry long.
[2004-06-16 17:28:42] phpbugs at spam dot raszi dot hu
It would be better if the file modification functions invalidate not the
whole statcache, only the entry of the modified file.
[2004-06-16 16:29:51] poll...@php.net
Ilia was perhaps a bit short winded in his response...
This was actually discussed within the context of a feature change as
well and was turned down on the basis that it would create unnecessary
slowdowns without significant gain.
You should be aware when you're making multiple stat family calls to the
same file and call clearstatcache() accordingly. If you're uncertain,
then just call it anyway.
However, that said it may be prudent to introduce an .ini option to
disable the cache altogether now that stat calls work on arbitrary
wrappers. Let's leave this option open for PHP 5.1 for now.
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/bug.php?id=28790
--
Edit this bug report at http://bugs.php.net/bug.php?id=28790&edit=1
Req #28790 [Asn]: Add php.ini option to disable stat cache
Edit report at http://bugs.php.net/bug.php?id=28790&edit=1
ID: 28790
Updated by: ras...@php.net
Reported by:jnoll at prim dot hu
Summary:Add php.ini option to disable stat cache
Status: Assigned
Type: Feature/Change Request
Package:*General Issues
Operating System: *
PHP Version:*
Assigned To:pollita
Block user comment: N
Private report: N
New Comment:
You guys realize that the stat cache is per-request, right? You only
need to
clear the stat cache before a file_exists() call if you A. did a stat
for it, and
B. either created or deleted it on that request. In which case you
shouldn't need
to stat it again since the success status of the create/delete will tell
you
whether the file is there or not. Perhaps for long-running daemons or
something
this becomes more of an issue, but for a typical web request the stat
cache
typically saves you dozens of system calls.
Previous Comments:
[2011-03-31 06:47:29] giorgio dot liscio at email dot it
when this will be fixed?
when lot of users work on same files is needed to clear the cache on
every call to stat functions: this is totally annoying
in plus clearing the cache every time is slower against not cache at
all
please fix :)
thank you
[2007-05-23 22:57:09] bcurry at freeshell dot org
I'd like to second the motion for an .INI-option enabling the stat
cache, defaulting to 'true.' In my case, I would certainly set this
option to 'false.'
In my humble opinion, the stat cache should either invalidate itself on
every file access and modification - or not cache entries, at all. I
depend on "file_exists" returning 'true' if a file exists, and 'false'
if not. Enabling the stat cache makes this (and similar) built-in
functions behave non-deterministically, and therefore un-reliably. The
"speed" gain of caching stat results is surely obviated by the fact
that, to obtain reliable stat results, one must call "clearstatcache"
before every call to the "file_exists" (and similar) built-in functions.
[2006-12-31 09:17:43] james at bytehosting dot com
When writing a daemon process that accesses files very often it seems
litterally stupid to cache stat on these files.
With Basic Code such as the below, the statcache adds unneccessary
overhead and actully SLOWS down the code caching & purging the cache on
EACH and EVERY revolution of code.
There MUST be an option to disable it, other than rm -rf'ing the stuff
from the src/.
Regardless if you believe its "quicker" or not is moot, for each and
every case that you give where it is quicker, I can garuntee to give you
a seperate case proving where it slows the code down.
If your not willing to add a config option, how about a runtime option?
(after all, who needs ob_implicit_flush()? its just another 'useless'
function..., same idioligy applies here). And there are PLUNTY of cases
where code such as this is required (obviously, not the exact code, its
pseudo code)
while (TRUE) {
clearstatcache();
if (file_exists("file.tmp")) {
process_stuff;
}
}
[2004-06-16 17:30:45] poll...@php.net
I'll cut ya in on a secret: The statcache is only one entry long.
[2004-06-16 17:28:42] phpbugs at spam dot raszi dot hu
It would be better if the file modification functions invalidate not the
whole statcache, only the entry of the modified file.
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/bug.php?id=28790
--
Edit this bug report at http://bugs.php.net/bug.php?id=28790&edit=1
