# PHP 5.5.1 released

- Thread: https://externals.io/message/68185
- Original archive: https://news-web.php.net/php.internals/68185
- Started by Julien Pauli on 2013-07-19T08:26:54+00:00
- Messages: 17
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #68185 — Julien Pauli — 2013-07-19T08:26:54+00:00

URL: https://externals.io/message/68185#68185

Hi internals,

We just released PHP 5.5.1. This release includes bug fixes as well as a
security fix.
For changes in PHP 5.5.1, please consult the PHP 5 ChangeLog.

Release Announcement:
http://www.php.net/release_5_5_1.php<http://www.php.net/release_5_5_0.php>
Downloads:            http://www.php.net/downloads.php#v5.5
Changelog:
http://www.php.net/ChangeLog-5.php#5.5.<http://www.php.net/ChangeLog-5.php#5.5.0>
1

regards,

Julien Pauli & David Soria Parra

---

## #68186 — Ivan Enderlin @ Hoa — 2013-07-19T08:31:33+00:00

URL: https://externals.io/message/68185#68186 · In reply to: #68185

Congrats :-).



> Hi internals,
>
> We just released PHP 5.5.1. This release includes bug fixes as well as a
> security fix.
> For changes in PHP 5.5.1, please consult the PHP 5 ChangeLog.
>
> Release Announcement:
> http://www.php.net/release_5_5_1.php<http://www.php.net/release_5_5_0.php>
> Downloads:            http://www.php.net/downloads.php#v5.5
> Changelog:
> http://www.php.net/ChangeLog-5.php#5.5.<http://www.php.net/ChangeLog-5.php#5.5.0>
> 1
>
> regards,
>
> Julien Pauli & David Soria Parra
>

-- 
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/

---

## #68194 — Jan Ehrhardt — 2013-07-19T10:44:18+00:00

URL: https://externals.io/message/68185#68194 · In reply to: #68185

Julien Pauli in php.internals (Fri, 19 Jul 2013 10:26:54 +0200):
>We just released PHP 5.5.1. This release includes bug fixes as well as a
>security fix.

When I try to build this one Windows, it fails quite rapidly. How do I
solve that?

Jan

C:\php-sdk\php55dev>nmake snap

Microsoft (R) Program Maintenance Utility Version 11.00.50727.1
Copyright (C) Microsoft Corporation.  All rights reserved.

Recreating build dirs
Recreating build dirs
Recreating build dirs
Recreating build dirs
        bison.exe --output=Zend/zend_ini_parser.c -v -d -p ini_ Zend/zend_ini_parser.y
        bison.exe --output=Zend/zend_language_parser.c -v -d -p zend Zend/zend_language_parser.y
zend/zend_language_parser.y:50: unrecognized: %code
zend/zend_language_parser.y:50:    Skipping to next %
NMAKE : fatal error U1077: 'c:\php-sdk\win32build\bin\bison.exe' : return code '0x1'
Stop.

---

## #68196 — Anatol Belski — 2013-07-19T11:01:14+00:00

URL: https://externals.io/message/68185#68196 · In reply to: #68194

Hi Jan,

I've just tried to make a snapshot build and it's worked. Please give the
exact way you do it from the start.

Regards

Anatol


> Julien Pauli in php.internals (Fri, 19 Jul 2013 10:26:54 +0200):
>
> > […]
>
> When I try to build this one Windows, it fails quite rapidly. How do I
> solve that?
>
> Jan
>
>
> C:\php-sdk\php55dev>nmake snap
>
>
> Microsoft (R) Program Maintenance Utility Version 11.00.50727.1
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
>
> Recreating build dirs
> Recreating build dirs
> Recreating build dirs
> Recreating build dirs
> bison.exe --output=Zend/zend_ini_parser.c -v -d -p ini_
> Zend/zend_ini_parser.y
> bison.exe --output=Zend/zend_language_parser.c -v -d -p zend
> Zend/zend_language_parser.y
> zend/zend_language_parser.y:50: unrecognized: %code
> zend/zend_language_parser.y:50:    Skipping to next %
> NMAKE : fatal error U1077: 'c:\php-sdk\win32build\bin\bison.exe' : return
> code '0x1' Stop.

---

## #68197 — johannes@schlueters.de — 2013-07-19T11:31:25+00:00

URL: https://externals.io/message/68185#68197 · In reply to: #68194

> C:\php-sdk\php55dev>nmake snap
[..]
>         bison.exe --output=Zend/zend_ini_parser.c -v -d -p ini_ Zend/zend_ini_parser.y
>         bison.exe --output=Zend/zend_language_parser.c -v -d -p zend Zend/zend_language_parser.y
> zend/zend_language_parser.y:50: unrecognized: %code
> zend/zend_language_parser.y:50:    Skipping to next %
> NMAKE : fatal error U1077: 'c:\php-sdk\win32build\bin\bison.exe' : return code '0x1'
> Stop.

Release tarballs should have pregenerated parses so this step shouldn't
be needed .. that aside: which version of bison are you using?

johannes

---

## #68200 — Jan Ehrhardt — 2013-07-19T12:17:58+00:00

URL: https://externals.io/message/68185#68200

Jan Ehrhardt in php.internals (Fri, 19 Jul 2013 14:03:51 +0200):
>http://windows.php.net/downloads/releases/php-5.5.1-src.zip does not
>contain a zend_language_parser.c.
>The php-5.5.1.tar.xz does...

http://windows.php.net/downloads/releases/archives/php-5.5.0-src.zip did
not contain a zend_language_parser.c either. I guess I was just lucky
grabbing the right sources up until now.

Jan

---

## #68199 — johannes@schlueters.de — 2013-07-19T12:20:21+00:00

URL: https://externals.io/message/68185#68199

> Johannes Schlüter in php.internals (Fri, 19 Jul 2013 13:31:25 +0200):
> > […]
> 
> http://windows.php.net/downloads/releases/php-5.5.1-src.zip does not
> contain a zend_language_parser.c.
> The php-5.5.1.tar.xz does...

Then those zips are wrong imo. The version used has impact on the
behavior (even if only in error messages) so only the ones approved by
the RM should be used for releases. (developers and "power users" may do
what they want, but we should have a unified behavior for normal users)

> > […]
> 
> GNU Bison version 1.27 ;-(

The Unix build system checks for one of those versions
  # we only support certain bison versions
  bison_version_list="2.4 2.4.1 2.4.2 2.4.3 2.5 2.5.1 2.6 2.6.1 2.6.2
2.6.3 2.6.4 2.6.5 2.7"
in Zend/acinclude.m4 maybe we should do the same in the windows
buildsystem. 

johannes

---

## #68202 — johannes@schlueters.de — 2013-07-19T13:33:55+00:00

URL: https://externals.io/message/68185#68202

> Normal users do not generally build PHP, but there is a chance they use
> a build system for compiling special extensions, Then it would be nice
> if the zips contain the pregenerated parses.

On http://windows.php.net/snapshots/ we provide development packages
which allow a phpize-configure-nmake workflow similar to the Unix system
without building the whole of PHP. Last time I tried this worked nicely.
I do not know why that is not done for releases, too. (also follow the
link there to http://windows.php.net/downloads/snaps/ ... not sure why
the website has outdated versions ...)

And another comparison to the Unix system: we have snaps.php.net which
distributes pregenerated parsers for "normal" users and git for people
who know what they do and have bison. Also sources from
php.net/downloads.php have pregenerated parsers.

> BTW: I am now running into another error, but I do not rule out it has
> to do with my own setup.
[...]
> Are you using Update 2 of VC11?
> http://blogs.msdn.com/b/somasegar/archive/2013/04/04/visual-studio-2012-update-2-now-available.aspx

There I can't help. I currently don't own a Windows license I could use
for that.

johannes

---

## #68203 — Anatol Belski — 2013-07-19T14:05:11+00:00

URL: https://externals.io/message/68185#68203 · In reply to: #68200

> Jan Ehrhardt in php.internals (Fri, 19 Jul 2013 14:03:51 +0200):
>
> > […]
>
> http://windows.php.net/downloads/releases/archives/php-5.5.0-src.zip did
> not contain a zend_language_parser.c either. I guess I was just lucky
> grabbing the right sources up until now.
>

Using bins from http://windows.php.net/downloads/php-sdk/ or directly
cloning https://github.com/OSTC/php-sdk-binary-tools has bison 2.4 binary
at least.

Regards

Anatol

---

## #68219 — Jan Ehrhardt — 2013-07-19T19:46:50+00:00

URL: https://externals.io/message/68185#68219 · In reply to: #68203

"Anatol Belski" in php.internals (Fri, 19 Jul 2013 16:05:11 +0200):
>Using bins from http://windows.php.net/downloads/php-sdk/

There is no doubt that I have used this before, given the fact that
other files like the phpsdk_buildtree.bat were also in my deps dir. But
I must have used it before 15 sep 2011, when a 'Copy of bison.exe' (the
old one) was made and the new one was put in place of the old one.

Jan

---

## #68224 — johannes@schlueters.de — 2013-07-19T20:57:26+00:00

URL: https://externals.io/message/68185#68224

> It would be really handy if there were phpize-configure-nmake packages
> for Windows releases as well.

Well,the ones from the snapshots should work nicely. I hope snaps use
similar compilation settings to releases.

>  Pierre recently asked me why I always
> build PHP completely with all the extensions.

I think it is good if more people do this. (Same for *BSD, HP-UX, AiX,
Solaris, ...)

johannes

---

## #68225 — Jan Ehrhardt — 2013-07-19T21:08:17+00:00

URL: https://externals.io/message/68185#68225 · In reply to: #68203

"Anatol Belski" in php.internals (Fri, 19 Jul 2013 16:05:11 +0200):
>Using bins from http://windows.php.net/downloads/php-sdk/

The 1999 version of bison.exe is still alive and kicking in
http://windows.php.net/downloads/php-sdk/php-sdk-binary-tools-20110512.zip
...

No chance that any normal Windows user will run it, because the path to
bison.simple is hardcoded as c:/usr/local/lib/bison.simple. but still it
is worth removing.

Jan

---

## #68227 — Jan Ehrhardt — 2013-07-19T21:31:41+00:00

URL: https://externals.io/message/68185#68227

Jan Ehrhardt in php.internals (Fri, 19 Jul 2013 22:42:14 +0200):
> > […]
>
>This question was a general question. The first 5.5 RC's were made
>public before Update 2 of VC11. They must have been build with Update 1.
>Are the official builds now compiled by VC2012.2?

Or rather by VC11, Update 3:
http://www.microsoft.com/en-us/download/details.aspx?id=39305

Apachelounge compiles Apache now with VC2012.3:
http://www.apachelounge.com/viewtopic.php?t=5456

Jan

---

## #68228 — Gustavo Lopes — 2013-07-19T23:36:04+00:00

URL: https://externals.io/message/68185#68228

>
> Sometimes you run into weird things. Today I learned that upgrading to
> ICU51 works perfectly under x64, but x86 stumbles over it and fails to
> compile php_intl.dll. No wonder the official builds still stick to
> 50.1.2.
>

I doubt it. I built the PECL/intl binaries in 
http://pecl.php.net/package/intl with ICU 51 with no problem and the 
codebase is very similar to that of ext/intl. But if you did find a bug, 
please report it.

-- 
Gustavo Lopes

---

## #68230 — Jan Ehrhardt — 2013-07-20T00:15:31+00:00

URL: https://externals.io/message/68185#68230 · In reply to: #68228

Gustavo Lopes in php.internals (Sat, 20 Jul 2013 01:36:04 +0200):
>
> > […]
>
>I doubt it. I built the PECL/intl binaries in 
>http://pecl.php.net/package/intl with ICU 51 with no problem and the 
>codebase is very similar to that of ext/intl. But if you did find a bug, 
>please report it.

OK, I will try that as well. But did you try it with VC11? I only see a
reference to VC9 at pecl.php.net. In december 2012 there still was a
difference between the PECL intl and the internal intl:
http://permalink.gmane.org/gmane.comp.php.devel/77370

This time I got other faults (all kinds of unresolved externals), that
were solved when I replaced the ICU51 files (download from the ICU site)
by the ICU50 files (also downloaded from the ICU site).

Jan

---

## #68233 — Jan Ehrhardt — 2013-07-20T01:12:19+00:00

URL: https://externals.io/message/68185#68233 · In reply to: #68228

Gustavo Lopes in php.internals (Sat, 20 Jul 2013 01:36:04 +0200):
>I doubt it. I built the PECL/intl binaries in 
>http://pecl.php.net/package/intl with ICU 51 with no problem and the 
>codebase is very similar to that of ext/intl. But if you did find a bug, 
>please report it.

Earlier today I compiled php-5.5.1-nts-Win32-VC11-x86.zip
Link here: http://www.apachelounge.com/viewtopic.php?t=5480

Then I replaced the ICU files in my build environment with these files:
http://download.icu-project.org/files/icu4c/51.2/icu4c-51_2-Win32-msvc10.zip

Exactly the same build script produced these errors:
http://pastebin.com/7S0XpfVY

That ended with:
rulebasedbreakiterator_methods.obj : error LNK2001: unresolved external
symbol "public: virtual void __thiscall
icu_51::RuleBasedBreakIterator::setText(struct UText *,enum UErrorCode
&)"
(?setText@RuleBasedBreakIterator@icu_51@@UAEXPAUUText@@AAW4UErrorCode@@@Z)
Release\php_intl.dll : fatal error LNK1120: 437 unresolved externals

Replacing the intl from the release by the one from PECL did not make
any difference. Same unresolved internals.

Switching to VC9 produced a workable PHP, that I have just uploaded to
my dropbox:
https://dl.dropboxusercontent.com/u/8954372/php-5.5.1-nts-Win32-VC9-x86.zip

As far as I remember from earlier today, VC10 stumbled over the same
unresolved externals. I will check that and will only report it if VC10
does not stumble.

Jan

---

## #68274 — Anatol Belski — 2013-07-21T12:31:51+00:00

URL: https://externals.io/message/68185#68274

Jan,

On Fri, 2013-07-19 at 23:25 +0200, Jan Ehrhardt wrote: 
> Sometimes you run into weird things. Today I learned that upgrading to
> ICU51 works perfectly under x64, but x86 stumbles over it and fails to
> compile php_intl.dll. No wonder the official builds still stick to
> 50.1.2.
> 

There was some tickets about ICU 51, like #64991. But while trying with
VC11 i had no issue with ICU itself. However there was too much PHP
tests failing, obviously due to differences between 50 and 51 in the
conversion area. As that was already PHP 5.5 beta phase, upgrading ICU
once more wasn't very feasible option. Once you have ICU 51 before it
gets officially upgraded, feel free to fix the test fails in PHP, as
that's the reason why it wasn't upgraded so fast :)

Regards

Anatol