PHP 5.3.0RC4 View as Markdown

Hello!

we have packaged PHP 5.3.0RC4, which you can find here:
http://downloads.php.net/johannes/

Windows binaries are available here:
http://windows.php.net/qa/

This this release candidate focused on bug fixes and stability
improvements and we hope to only require minimal changes ahead
of the next release. Many, but not all, of the new features are
already integrated in the official documentation on php.net.

We aim to release PHP 5.3.0 next week. In case of critical issues we
will continue producing weekly RCs. For most users there will not be a
noticeable change meaning that now is the time to really do the final
testing of PHP 5.3.0 before it gets released with any unnecessary
incompatibilities with your project.

We are really close, however there is obviously a steady stream of new
tickets being opened [1]. Some of these include bugs in new
functionality and some include BC breaks. At this point Johannes and I
are not aware of any show stopper bugs yet though. We very much
appreciate every effort to review those bug reports and as much
testing as possible with real world applications. Please let us know
ASAP if you do think that there is a show stopper bug.

Also please do not commit to 5_3 without the explicit permission of
Johannes. Please post any 5_3 patches to internals for peer review. We
have had a few last minute commits break things and so we ask you to
accept this additional step before commits for the hopefully short
time period until 5.3.0 stable.

Best Regards,
Lukas and Johannes
PHP 5.3 Release Managers

[1] http://bugs.php.net/search.php?status=Open&phpver=5.3&cmd=display

Hallo,

I just wanted to compile PHP 5.3.0RC4 on my Solaris 10 box:

pangaeaw@pansrv1:~/install/php-5.3.0RC4$ gcc -v

Reading specs from /opt/csw/gcc3/lib/gcc/i386-pc-solaris2.8/3.4.5/specs

Configured with: ../sources/gcc-3.4.5/configure --prefix=/opt/csw/gcc3
--with-local-prefix=/opt/csw --with-gnu-as --with-as=/opt/csw/bin/gas
--without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix
--enable-shared --enable-multilib --enable-nls --with-included-gettext
--with-libiconv-prefix=/opt/csw --with-x --enable-java-awt=xlib
--enable-languages=all

Thread model: posix

gcc version 3.4.5

and got a compilation failure:

/bin/sh /pangaea/install/php-5.3.0RC4/libtool --silent --preserve-dup-deps
--mode=compile gcc -I/pangaea/install/php-5.3.0RC4/ext -I -Iext/pdo_mysql/
-I/pangaea/install/php-5.3.0RC4/ext/pdo_mysql/ -DPHP_ATOM_INC
-I/pangaea/install/php-5.3.0RC4/include -I/pangaea/install/php-5.3.0RC4/main
-I/pangaea/install/php-5.3.0RC4 -I/pangaea/webserver70/include
-I/pangaea/install/php-5.3.0RC4/ext/date/lib
-I/pangaea/install/php-5.3.0RC4/ext/ereg/regex -I/opt/csw/include/libxml2
-I/opt/csw/include -I/pangaea/install/php-5.3.0RC4/ext/mbstring/oniguruma
-I/pangaea/install/php-5.3.0RC4/ext/mbstring/libmbfl
-I/pangaea/install/php-5.3.0RC4/ext/mbstring/libmbfl/mbfl
-I/opt/csw/mysql5/include/mysql -I/usr/include/libxml2
-I/pangaea/install/php-5.3.0RC4/TSRM -I/pangaea/install/php-5.3.0RC4/Zend
-D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT
-I/opt/csw/include -g -O2 -DZTS -c
/pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c -o
ext/pdo_mysql/mysql_statement.lo

/pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c: In function
`pdo_mysql_stmt_dtor':

/pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:52: error:
structure has no member named `stmt'

/pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:70: error:
structure has no member named `params'

/pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:71: error:
structure has no member named `params'

/pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:73: error:
structure has no member named `in_null'

/pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:74: error:
structure has no member named `in_null'

/pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:76: error:
structure has no member named `in_length'

/pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:77: error:
structure has no member named `in_length'

/pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c: In function
`pdo_mysql_stmt_set_row_count':

/pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:127: error:
structure has no member named `stmt'

/pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c: In function
`pdo_mysql_stmt_execute':

/pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:295: error:
structure has no member named `stmt'

/pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c: In function
`pdo_mysql_stmt_describe':

/pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:678: error:
structure has no member named `stmt'

/pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c: In function
`pdo_mysql_stmt_get_col':

/pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:727: error:
structure has no member named `stmt'

/pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c: In function
`pdo_mysql_stmt_col_meta':

/pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:831: error:
structure has no member named `stmt'

/pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c: In function
`pdo_mysql_stmt_cursor_closer':

/pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:898: error:
structure has no member named `stmt'

gmake: *** [ext/pdo_mysql/mysql_statement.lo] Error 1

Is this a known bug?

Uwe

Uwe Schindler

thetaphi@php.net - http://www.php.net

NSAPI SAPI developer

Bremen, Germany

-----Original Message-----

From: Lukas Kahwe Smith [mailto:mls@pooteeweet.org]

Sent: Friday, June 19, 2009 10:51 AM

To: internals@lists.php.net; php-general@lists.php.net

Subject: [PHP-DEV] PHP 5.3.0RC4

Hello!

we have packaged PHP 5.3.0RC4, which you can find here:

http://downloads.php.net/johannes/

Windows binaries are available here:

http://windows.php.net/qa/

This this release candidate focused on bug fixes and stability

improvements and we hope to only require minimal changes ahead

of the next release. Many, but not all, of the new features are

already integrated in the official documentation on php.net.

We aim to release PHP 5.3.0 next week. In case of critical issues we

will continue producing weekly RCs. For most users there will not be a

noticeable change meaning that now is the time to really do the final

testing of PHP 5.3.0 before it gets released with any unnecessary

incompatibilities with your project.

Some additional links to get started:

http://cvs.php.net/viewvc.cgi/php-src/NEWS?view=markup&pathrev=PHP_5_3

http://cvs.php.net/viewvc.cgi/php-src/UPGRADING?revision=PHP_5_3

Best Regards,

Lukas and Johannes

PHP 5.3 Release Managers

Lukas Kahwe Smith wrote:

Some additional links to get started:
http://cvs.php.net/viewvc.cgi/php-src/NEWS?view=markup&pathrev=PHP_5_3
http://cvs.php.net/viewvc.cgi/php-src/UPGRADING?revision=PHP_5_3

While I know that ...

• All ereg functions are deprecated and emit E_DEPRECATED errors.
  Use PCRE (preg_*()) instead.

... is accurate, I think a little more detail would help here, since
many of us probably did not know that 'split' was an ereg function - for
instance?

I THINK that split() maps to explode() without needing any mapping of
the parameters?

But ereg_replace to preg_replace is not quite so easy? and when looking
to convert someone else's legacy code, trying to understand some
mappings can be a problem. Does anybody have a useful reference that
would help in converting from one to the other?

Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

Lukas Kahwe Smith wrote:

Johannes Schlüter wrote:

While I know that ...

• All ereg functions are deprecated and emit E_DEPRECATED errors.
  Use PCRE (preg_*()) instead.

... is accurate, I think a little more detail would help here,
since many of us probably did not know that 'split' was an ereg
function - for instance?
hm, the las version on the wiki listed them ...
In general: I'd like if people could come up with more details
and add
them to the docs. (See Rasmus's mail) So that this file is as
short as i
makes sense so people have a chance to be aware of as much
contents as
possible - and isn't scared away.

I was probably looking more for pointers to some extra
information. Part of the problem here is that the warnings are
being thrown in code that I did not write, so then one either
has to search for updated versions of a library or work out how
to fix them yourself - where I'd 'borrowed' the code originally.
Simply hiding E_DEPRECATED is likely to lead to even bigger
blowups later? :(
Actually E_DEPRECATED is only something you should enable
temporarily. Then you can alert either your own team, or the
project who's code you are using and move on. It simply tells you
that the code will break with the next major version. This is not
an end of world fatal error.

On a production site - probably - but I see no reason to disable it
on the development sites. It's all to easy to grab a bit of code
and drop it in, forgetting that it's now on the 'deprecated' list.
I avoid libraries that throw errors and will only work with
'display_errors=off'. If I need to use them then I will fix any
errors even if 'non-fatal' before using the code in production! So
before PHP5.3 is acceptable for production, any warning needs to be
addressed - at least in my book.

There is a reason why E_DEPRECATED isn't part of E_ALL. Anyways, its
your call, but its not what we suggest. But overall there is always
room for doc improvements (feel free to help out), but in the end
you need to know the code or familiarize yourself with the code if
you want to "fix" it, though per se .. there is nothing broken with
the code in the current version of PHP.

Ok, guess I am wrong here. Its part of E_ALL as I suggested it when I
proposed E_DEPRECATED initially. Since it seems I was the only one
that considered not including it in E_ALL.

That being said, for development we currently suggest:
error_reporting = E_ALL | E_STRICT

And for production:
error_reporting = E_ALL & ~E_DEPRECATED

So I guess we are pushing people towards fixing deprecation issues a
bit more forcefully than I thought.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org