[PHP-BUG] Bug #66017 [NEW]: Linking fails when trying to use atomic_add_int and membar_producer
From: Pete_Wall at symantec dot com
Operating system: Solaris 10 SPARC
PHP version: 5.4.21
Package: *Encryption and hash functions
Bug Type: Bug
Bug description:Linking fails when trying to use atomic_add_int and
membar_producer
Description:
I'm trying to build PHP 5.4.21 on my Solaris 10 SPARC box, but it's
failing when it tries to link in atomic_add_int and membar_producer.
Both of those functions are used in ext/standard/php_crypt_r.c:
80 void _crypt_extended_init_r(void)
81 {
82 #ifdef PHP_WIN32
83 LONG volatile initialized = 0;
84 #elif defined(HAVE_ATOMIC_H) /* Solaris 10 defines atomic API within
*/
85 volatile unsigned int initialized = 0;
86 #else
87 static volatile sig_atomic_t initialized = 0;
88 #endif
89
90 #ifdef ZTS
91 tsrm_mutex_lock(php_crypt_extended_init_lock);
92 #endif
93
94 if (!initialized) {
95 #ifdef PHP_WIN32
96 InterlockedIncrement(initialized);
97 #elif defined(HAVE_SYNC_FETCH_AND_ADD)
98 __sync_fetch_and_add(initialized, 1);
99 #elif defined(HAVE_ATOMIC_H) /* Solaris 10 defines atomic API within
*/
100 membar_producer();
101 atomic_add_int(initialized, 1);
102 #endif
103 _crypt_extended_init();
104 }
105 #ifdef ZTS
106 tsrm_mutex_unlock(php_crypt_extended_init_lock);
107 #endif
108 }
On my version of glibc, atomic_add_int() and membar_producer aren't
defined.
$ nm -g /lib/libc.so.1 | grep atomic_add_int
$ nm -g /lib/libc.so.1 | grep membar_producer
Compiler and configuration info:
CFLAGS=
CPPFLAGS= -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
./configure --disable-cgi --enable-cli --prefix=/path/to/php
--with-libxml-dir=/path/to/libxml
--with-openssl=shared,/path/to/openssl
--with-zlib=/path/to/zlib --with-curl=shared,/path/to/curl
--with-config-file-path=/path/to/cfgfile --with-layout=GNU
--with-regex=php --with-tsrm-pthreads --disable-rpath
--disable-sysvsem --disable-sysvshm
--disable-sysvmsg --disable-bcmath --disable-ctype --disable-exif
--disable-spl --disable-ftp
--disable-shmop --enable-tokenizer --disable-static
--enable-posix=shared --enable-session=shared
--enable-sockets=shared --enable-xml=shared --enable-pcntl=shared
--enable-dom --without-mm
--without-gettext --without-iconv --without-sqlite
--without-mime-magic --without-mysql --without-sybase-ct
--without-gdbm --without-db4 --without-cdb --without-pear
--without-xsl --disable-debug
--with-pcre-dir=/path/to/pcre --with-pcre-regex
$ gcc -v
Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.10/3.4.6/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++,f77
Thread model: posix
gcc version 3.4.6
$ uname -a
SunOS grampa 5.10 Generic sun4u sparc SUNW,Sun-Fire-V210
Snippet from configure output:
checking atomic.h usability... yes
checking atomic.h presence... yes
checking for atomic.h... yes
Expected result:
Successful linking
Actual result:
--
Undefined first referenced
symbol in file
atomic_add_int ext/standard/.libs/php_crypt_r.o
membar_producer ext/standard/.libs/php_crypt_r.o
ld: fatal: Symbol referencing errors. No output written to sapi/cli/php
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1
--
Edit bug report at https://bugs.php.net/bug.php?id=66017edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=66017r=trysnapshot54
Try a snapshot (PHP 5.5):
https://bugs.php.net/fix.php?id=66017r=trysnapshot55
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=66017r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=66017r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=66017r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=66017r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=66017r=needscript
Try newer version: https://bugs.php.net/fix.php?id=66017r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=66017r=support
Expected behavior: https://bugs.php.net/fix.php?id=66017r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=66017r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=66017r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=66017r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=66017r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=66017r=dst
IIS Stability: https://bugs.php.net/fix.php?id=66017r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=66017r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=66017r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=66017r=nozend
MySQL Configuration Error:
Req #50029 [Com]: Weird invoke issue on class as property
Edit report at https://bugs.php.net/bug.php?id=50029edit=1
ID: 50029
Comment by: worldoffame at hotmail dot com
Reported by:marc dot gray at gmail dot com
Summary:Weird invoke issue on class as property
Status: Analyzed
Type: Feature/Change Request
Package:Class/Object related
Operating System: Ubuntu 9.04
PHP Version:5.3.0
Block user comment: N
Private report: N
New Comment:
Has this bug been fixed yet? Its one of the most annoying glitches in PHP, and
funny it has existed for more than 4 years.
Previous Comments:
[2013-08-29 10:50:17] worldoffame at hotmail dot com
Also the argument that invoking class property could override class methods
itself is just nonsense. Guess what? Its a poor design if your method shares
the same name as your property anyway. If collision occurs it looks more like
an improper OOP practice to me.
[2013-08-29 10:44:14] worldoffame at hotmail dot com
Any updates on this? I hope it gets fixed asap, cant believe this bug has been
around for 3+ years and still left untouched. *sigh*
[2012-06-08 12:24:34] programmierung at pfink dot de
The worst thing on this bug is that is_callable() returns true in this case
even though it's not callable:
The lines
if(is_callable($this-objectWithInvokeMethod))
return $this-objectWithInvokeMethod(0);
produce the fatal error
Fatal error: Call to undefined method MyClass::objectWithInvokeMethod()
[2011-12-06 16:34:31] karsten at typo3 dot org
I would go for simple rules to solve this. When having a class and calling
$this-prop() PHP should
* use __invoke on $this-prop if there is no method prop() in the class
* if there is an actual method, the method takes precedence
In the latter one can still use $this-prop-__invoke(), but should probably
rather clean up the code. :)
[2011-08-24 18:49:06] marc dot gray at gmail dot com
I've been thinking about this since the same issue appears to exist with
assigning a closure to a static
variable too (tested in 5.3.5, 5.3.8 5.4alpha3.
//--
// Create a very basic static class
class closureProperty {
static public $myClosure;
}
// Assign a closure to a class property
closureProperty::$myClosure = function() { echo('Hi'); };
// Fatal error: Function name must be a string
closureProperty::$myClosure();
// Works as expected
$safeCopy = closureProperty::$myClosure;
$safeCopy();
//--
I can understand why it happens with dynamic properties, apparently you can
have a variable and function named
identically? I admit I've never tried.
I would propose making identically named variables and functions as deprecated
(does anyone who's any good
actually do that? Talk about poor readability...) and implement a collision
warning in the mean time. I would
also suggest this makes less sense in a static case (due to $ variable prefix)
than it did in a dynamic case,
and should be changed.
If nothing else, some discussion on the matter would be lovely.
Thoughts?
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=50029
--
Edit this bug report at https://bugs.php.net/bug.php?id=50029edit=1
Req #47785 [Opn-Csd]: get_included_files resolves symlinks
Edit report at https://bugs.php.net/bug.php?id=47785edit=1
ID: 47785
Updated by: krak...@php.net
Reported by:andre at webkr dot de
Summary:get_included_files resolves symlinks
-Status: Open
+Status: Closed
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
Operating System: Linux
PHP Version:5.2.9
-Assigned To:
+Assigned To:krakjoe
Block user comment: N
Private report: N
New Comment:
Symlinks are resolved to their full paths because it's the only sensible thing
to do.
If your application requires the relative path, it should be no problem to
discover it, being that if the path of the application is relevant information
then you should have it in a variable/constant somewhere.
This is a non-issue.
Previous Comments:
[2009-03-29 02:52:58] andre at webkr dot de
It's even worse:
When an included file includes another file using a relative path, that is
looked up in the target directory of the symlink!
It should be relative to the path where the symlink resides. The only access
types that should treat the symlink in a special way are unlink (it should
remove the symlink, not the target file) and chmod (it should do nothing). All
other access types (especially the read involved here) should see the symlink
as if it were a file with the content and attributes of the target file.
[2009-03-26 04:04:41] andre at webkr dot de
Description:
When a symlink is included/required, get_included_files shows the target of the
symlink. Together with Bug #46260 this makes it completely impossible to
determine how the file was really called when it was included.
Reproduce code:
---
include('path_to/a_symlink.php');
var_dump(get_included_files());
Expected result:
An array containing a string [...]/path_to/a_symlink.php.
Actual result:
--
An array containing a string [...]/some_file.php.
--
Edit this bug report at https://bugs.php.net/bug.php?id=47785edit=1
[PHP-BUG] Bug #66023 [NEW]: destruction problem
From: flobee at gmail dot com
Operating system: debian testing
PHP version: 5.5.5
Package: *General Issues
Bug Type: Bug
Bug description:destruction problem
Description:
calling methodes on destruction is difficult to understand when using
singelton patterns which does not make sence for me. maybe i'm wrong..
i'm not sure at the moment...
also: if session is used this fails on destruction
see script below for a simple test
i expect the call of knock() from master class on destruction of class
b.
when not using singelton patter all is fine. the order of the
destruction works.
this problems starts with php 5.5* packages in debian testing.
$ uname -a
Linux d1 3.10-3-686-pae #1 SMP Debian 3.10.11-1 (2013-09-10) i686
GNU/Linux
$ php -v
PHP 5.5.5-1 (cli) (built: Oct 19 2013 22:09:48)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2013 Zend Technologies
with Zend OPcache v7.0.3-dev, Copyright (c) 1999-2013, by Zend
Technologies
with Xdebug v2.2.3, Copyright (c) 2002-2013, by Derick Rethans
Test script:
---
?php
error_reporting( -1);
session_start();
interface Singleton_Interface
{
public static function getInstance();
}
abstract class Singleton implements Singleton_Interface
{
public function __clone()
{
throw new Exception( 'Clone is not allowed.' );
}
}
class master extends Singleton implements Singleton_Interface
{
private $r;
private static $instance;
public static function getInstance( $params=array( ) )
{
if( !isset(self::$instance) ) {
$c = __CLASS__;
self::$instance = new $c($params);
}
return self::$instance;
}
public function knock()
{
echo 'call ' . __METHOD__ . PHP_EOL;
}
public function __construct($r=false)
{
$this-r = $r;
echo __METHOD__ . PHP_EOL;
}
public function __destruct()
{
echo __METHOD__ . PHP_EOL;
if (method_exists($this-r, 'knock')) {
$this-r-knock();
}
$_SESSION['x'] = __METHOD__;
}
}
class b extends Singleton implements Singleton_Interface
{
private $r;
private static $instance;
public static function getInstance( $params=array( ) )
{
if( !isset(self::$instance) ) {
$c = __CLASS__;
self::$instance = new $c($params);
}
return self::$instance;
}
public function knock()
{
echo 'call ' . __METHOD__ . PHP_EOL;
}
public function __construct($r=false)
{
$this-r = $r;
echo __METHOD__ . PHP_EOL;
}
public function __destruct()
{
echo __METHOD__ . PHP_EOL;
if (method_exists($this-r, 'knock')) {
$this-r-knock();
}
$_SESSION['y'] = __METHOD__;
}
}
header( 'content-type: text/plain' );
echo 'session:'; print_r($_SESSION);
$master = master::getInstance();
$b = b::getInstance($master); // calls master-knock() on destruction
$master-knock();
$b-knock();
echo 'done' . PHP_EOL;
Actual result:
--
/* result:
master::__construct
b::__construct
call master::knock
call b::knock
done
master::__destruct
b::__destruct
call master::knock -- no error?
_session is empty! correct? wrong?
*/
--
Edit bug report at https://bugs.php.net/bug.php?id=66023edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=66023r=trysnapshot54
Try a snapshot (PHP 5.5):
https://bugs.php.net/fix.php?id=66023r=trysnapshot55
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=66023r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=66023r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=66023r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=66023r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=66023r=needscript
Try newer version: https://bugs.php.net/fix.php?id=66023r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=66023r=support
Expected behavior: https://bugs.php.net/fix.php?id=66023r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=66023r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=66023r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=66023r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=66023r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=66023r=dst
IIS Stability: https://bugs.php.net/fix.php?id=66023r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=66023r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=66023r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=66023r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=66023r=mysqlcfg
[PHP-BUG] Req #66024 [NEW]: mb_chr() and mb_ord()
From: yohgaki Operating system: * PHP version: Irrelevant Package: mbstring related Bug Type: Feature/Change Request Bug description:mb_chr() and mb_ord() Description: Although mb_encode/decode_numericentity() can be used for multibyte version of chr()/ord(), it would be better to have mb_chr() and mb_ord(). $char_code = mb_chr($mb_char [, $encoding = mbstring.internal_encoding] ) $mb_char = mb_ord($char_code [, $encoding = mbstring.internal_encoding] ) -- Edit bug report at https://bugs.php.net/bug.php?id=66024edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=66024r=trysnapshot54 Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=66024r=trysnapshot55 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=66024r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=66024r=fixed Fixed in release: https://bugs.php.net/fix.php?id=66024r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=66024r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=66024r=needscript Try newer version: https://bugs.php.net/fix.php?id=66024r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=66024r=support Expected behavior: https://bugs.php.net/fix.php?id=66024r=notwrong Not enough info: https://bugs.php.net/fix.php?id=66024r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=66024r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=66024r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=66024r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=66024r=dst IIS Stability: https://bugs.php.net/fix.php?id=66024r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=66024r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=66024r=float No Zend Extensions: https://bugs.php.net/fix.php?id=66024r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=66024r=mysqlcfg
