Dear PHP/Zend folks :
This is a bug I think. I recently saw that PHP had been updated to 5.4.10 and I
decided to update my php bits in /usr/local. I was quite surprised to see in the
configure output this warning about bison :
checking for bison... bison -y
checking for bison version... invalid
configure: WARNING: bison versions supported for regeneration of the Zend/PHP parsers: 1.28 1.35 1.75 1.875 2.0 2.1 2.2 2.3 2.4 2.4.1 2.4.2 2.4.3 2.5 2.5.1 2.6 2.6.1 2.6.2 (found: 2.6.5).
This seems odd to me as bison 2.6.5 builds and tests perfectly on my Solaris 10
server and so therefore I wonder what these PHP folks are on about? Is this a "Warning"
or a real configure fault? If the latter then I need to backout bison in order to build
PHP and then re-install a perfectly functional bison ?
Dennis Clarke
Dear PHP/Zend folks :
This is a bug I think. I recently saw that PHP had been updated to 5.4.10 and Idecided to update my php bits in /usr/local. I was quite surprised to see in the
configure output this warning about bison :checking for bison... bison -y
checking for bison version... invalid
configure: WARNING: bison versions supported for regeneration of the Zend/PHP parsers: 1.28 1.35 1.75 1.875 2.0 2.1 2.2 2.3 2.4 2.4.1 2.4.2 2.4.3 2.5 2.5.1 2.6 2.6.1 2.6.2 (found: 2.6.5).This seems odd to me as bison 2.6.5 builds and tests perfectly on my Solaris 10server and so therefore I wonder what these PHP folks are on about? Is this a "Warning"
or a real configure fault? If the latter then I need to backout bison in order to build
PHP and then re-install a perfectly functional bison ?Dennis Clarke
Unless you are hacking PHP you can ignore Bison. Check the Makefile
for where it is used. The PHP distribution contains
Zend/zend_language_parser.[ch] and php-5.5/Zend/zend_ini_parser.[ch]
already built from their respective .y files so bison is not
generally invoked when building PHP.
Of course, if 2.6.5 is verified than it should be added to
bison_version_list in Zend/acinclude.m4. Feel free to regenerate the
parsers with it, review the test suite results, and create a github
pull request.
Chirs
--
christopher.jones@oracle.com http://twitter.com/ghrd
Newly updated, free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
This is a bug I think. I recently saw that PHP had been updatedto 5.4.10 and I decided to update my php bits in /usr/local. I was
quite surprised to see in the configure output this warning about
bison :checking for bison... bison -y
checking for bison version... invalid
configure: WARNING: bison versions supported for regeneration of the
Zend/PHP parsers: 1.28 1.35 1.75 1.875 2.0 2.1 2.2 2.3 2.4 2.4.1 2.4.2 2.4.3
2.5 2.5.1 2.6 2.6.1 2.6.2 (found: 2.6.5).This seems odd to me as bison 2.6.5 builds and tests perfectlyon my Solaris 10 server and so therefore I wonder what these PHP
folks are on about? Is this a "Warning" or a real configure fault?
If the latter then I need to backout bison in order to build PHP and
then re-install a perfectly functional bison ?Unless you are hacking PHP you can ignore Bison. Check the Makefile
for where it is used. The PHP distribution contains
Zend/zend_language_parser.[ch] and php-5.5/Zend/zend_ini_parser.[ch]
already built from their respective .y files so bison is not generally
invoked when building PHP.Of course, if 2.6.5 is verified than it should be added to
bison_version_list in Zend/acinclude.m4. Feel free to regenerate the
parsers with it, review the test suite results, and create a github
pull request.
I think we should retire this silly check, as it needs updating every
time there is a new version. Instead, we should blacklist versions that
don't work.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
Unless you are hacking PHP you can ignore Bison. Check the Makefile
Well, the configure output claims that something is wrong, therefore the build can not be trusted.
I'm just following the defacto way to build PHP and if the configure output claims
something is wrong .. then it is wrong by definition.
for where it is used. The PHP distribution contains
Zend/zend_language_parser.[ch] and php-5.5/Zend/zend_ini_parser.[ch]already built from their respective .y files so bison is not
generally invoked when building PHP.
configure claims otherwise.
Of course, if 2.6.5 is verified than it should be added to
bison_version_list in Zend/acinclude.m4. Feel free to regenerate
the
parsers with it, review the test suite results, and create a github
pull request.
do what ? I access the release source tarball only.
gcc-spec_node002 $ digest -a sha1 /usr/local/src/php-5.4.10.tar.gz
6be6a1c16ca3f6bec93d19ce5d6b94c5cf89373b
That is the only php sources I am allowed to use. Anything else is not "release" and
therefore not to be used on prod servers.
I think we should retire this silly check, as it needs updating every
time there is a new version. Instead, we should blacklist versions
that don't work.
Well bison 2.6.5 passes all of its own tests and therefore seems to be "okay for prod".
I would think that a PHP release would build more or less out of the box without any
changes to the source tarball. If PHP can not be built from the release tarball with
the typical GNU toolchain then .. it can't be built. I just tick off a box on the build
sheet here as "does not build in compliance with defacto standard rules" and it goes
back onto the "update at some point" pile.
Dennis
ps: typical GNU tools like :
gcc-spec_node002 $ which bison
/usr/local/bin/bison
gcc-spec_node002 $ bison --version
bison (GNU Bison) 2.6.5
Written by Robert Corbett and Richard Stallman.
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
gcc-spec_node002 $ automake --version
automake (GNU automake) 1.13
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later http://gnu.org/licenses/gpl-2.0.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Tom Tromey tromey@redhat.com
and Alexandre Duret-Lutz adl@gnu.org.
gcc-spec_node002 $
gcc-spec_node002 $ gmake --version
GNU Make 3.82
Built for sparc-sun-solaris2.10
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
gcc-spec_node002 $ gsed --version
GNU sed version 4.2.1
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE,
to the extent permitted by law.
GNU sed home page: http://www.gnu.org/software/sed/.
General help using GNU software: http://www.gnu.org/gethelp/.
E-mail bug reports to: bug-gnu-utils@gnu.org.
Be sure to include the word sed'' somewhere in theSubject:'' field.
gcc-spec_node002 $
gcc-spec_node002 $ which runtest
/usr/local/bin/runtest
gcc-spec_node002 $
gcc-spec_node002 $ runtest --version
WARNING: Couldn't find the global config file.
Expect version is 5.45
Tcl version is 8.5
Framework version is 1.5
gcc-spec_node002 $
etc
etc
etc ...
On Tue, Jan 15, 2013 at 9:05 PM, Dennis Clarke dclarke@blastwave.orgwrote:
Unless you are hacking PHP you can ignore Bison. Check the Makefile
Well, the configure output claims that something is wrong, therefore the
build can not be trusted.
I'm just following the defacto way to build PHP and if the configure
output claims
something is wrong .. then it is wrong by definition.for where it is used. The PHP distribution contains
Zend/zend_language_parser.[ch] and php-5.5/Zend/zend_ini_parser.[ch]already built from their respective .y files so bison is not
generally invoked when building PHP.configure claims otherwise.
Of course, if 2.6.5 is verified than it should be added to
bison_version_list in Zend/acinclude.m4. Feel free to regenerate
the
parsers with it, review the test suite results, and create a github
pull request.do what ? I access the release source tarball only.
gcc-spec_node002 $ digest -a sha1 /usr/local/src/php-5.4.10.tar.gz
6be6a1c16ca3f6bec93d19ce5d6b94c5cf89373bThat is the only php sources I am allowed to use. Anything else is not
"release" and
therefore not to be used on prod servers.I think we should retire this silly check, as it needs updating every
time there is a new version. Instead, we should blacklist versions
that don't work.Well bison 2.6.5 passes all of its own tests and therefore seems to be
"okay for prod".I would think that a PHP release would build more or less out of the box
without any
changes to the source tarball. If PHP can not be built from the release
tarball with
the typical GNU toolchain then .. it can't be built. I just tick off a
box on the build
sheet here as "does not build in compliance with defacto standard rules"
and it goes
back onto the "update at some point" pile.
currently we have a whitelist for supported bison versions:
http://lxr.php.net/xref/PHP_5_4/Zend/acinclude.m4#6
anything else will be reported, but this doesn't mean that php wouldn't
compile with that, it can also mean that nobody tested and made sure that
it works.
this is why Derick mentioned that he thinks we should switch to a
blacklist, so we only report the versions with known problems.
ps: your passive aggressive tone doesn't really help your case here.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
currently we have a whitelist for supported bison versions:
http://lxr.php.net/xref/PHP_5_4/Zend/acinclude.m4#6
anything else will be reported, but this doesn't mean that php wouldn't
compile with that, it can also mean that nobody tested and made sure that
it works.
this is why Derick mentioned that he thinks we should switch to a
blacklist, so we only report the versions with known problems.ps: your passive aggressive tone doesn't really help your case here.
Yes, sorry about that. It was the end of a long day and I was on the last of the coffee
and can be a jerk at times. I am generally a very productive jerk, but still a jerk. Sorry.
I'll go an see if I can isolate those failures on Solaris and maybe triage a few things. Get
a handle on what is really a concern and what is a "wow, it needed GNU sed not XPG4
sed" type of thing.
Dennis
Of course, if 2.6.5 is verified than it should be added to
bison_version_list in Zend/acinclude.m4. Feel free to regenerate the
parsers with it, review the test suite results, and create a github
pull request.
Anything outside of "release tarball" won't be supported here. Sorry.
However ... having said that, it is certainly worth the attempt.
Question for you, ever seen PHP build on Solaris 10 with mysql ( in .opt/mysql
as per MySQL Release Engineering packages ) and have it pass its own testsuite?
I never have.
Dennis
Of course, if 2.6.5 is verified than it should be added to
bison_version_list in Zend/acinclude.m4. Feel free to regenerate the
parsers with it, review the test suite results, and create a github
pull request.Anything outside of "release tarball" won't be supported here. Sorry.
However ... having said that, it is certainly worth the attempt.Question for you, ever seen PHP build on Solaris 10 with mysql ( in .opt/mysql
as per MySQL Release Engineering packages ) and have it pass its own testsuite?
I rarely build on Solaris. Other messages in this thread mention how
you can assist the PHP community in resolving any issues you do see.
Are you building a specific PHP version for a reason? Can you use the
pre-built Solaris PHP packages in some situations (e.g. see the
Solaris chapter in
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html)
Chris
--
christopher.jones@oracle.com http://twitter.com/ghrd
Newly updated, free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
Of course, if 2.6.5 is verified than it should be added to
bison_version_list in Zend/acinclude.m4. Feel free to regenerate the
parsers with it, review the test suite results, and create a github
pull request.Anything outside of "release tarball" won't be supported here. Sorry.
However ... having said that, it is certainly worth the attempt.Question for you, ever seen PHP build on Solaris 10 with mysql
( in /opt/mysql as per MySQL Release Engineering packages ) and
have it pass its own testsuite?I rarely build on Solaris. Other messages in this thread mention how
you can assist the PHP community in resolving any issues you do see.
I see. Well I am not new to this and knew that there would be issues. The general
modus operandi of most people is to ditch the problem OS and switch over to
Red Hat or maybe SUSE but the software investment here is too great. The switch
over would be long and costly etc etc etc. Also, there are financial institutions that
still love their UNIX servers ( Solaris ) and are unlikely to let go anytime soon. Maybe
you could have a word with the executive board at Oracle and get them to stop
making newer bigger Sparc servers and exadata storage? ;-)
Are you building a specific PHP version for a reason? Can you use the
pre-built Solaris PHP packages in some situations (e.g. see the
Solaris chapter in
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html)
I was not aware that Oracle had pre-built PHP packages. I can only assume
that they would install with typical SVR4 packages into Solaris 10 and then
be subject to maintenance under a typical MOS contract? If not, then I am
stuck doing the port work myself.
As for the version, well, the production release version seems like a good way to
go. That seems to be PHP 5.4.10 at the moment and unless someone says that it
is bleeding edge beta grade ... it makes sense to compile it.
I am going to go check out your link there and, perhaps, stay in touch. from what I
gather by reading between the lines no one is in a hurry at Oracle to do anything
on Solaris either. At least, seems that way.
Dennis