# PHP 5.4.10 can not build Zend/PHP parsers with bison 2.6.5 - Thread: https://externals.io/message/64963 - Original archive: https://news-web.php.net/php.internals/64963 - Started by Dennis Clarke on 2013-01-15T01:16:18+00:00 - Messages: 9 - 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 --- ## #64963 — Dennis Clarke — 2013-01-15T01:16:18+00:00 URL: https://externals.io/message/64963#64963 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 --- ## #64965 — Christopher Jones — 2013-01-15T03:35:07+00:00 URL: https://externals.io/message/64963#64965 · In reply to: #64963 > > 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 > 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 --- ## #64969 — Derick Rethans — 2013-01-15T10:37:09+00:00 URL: https://externals.io/message/64963#64969 · In reply to: #64965 > > > […] > > 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 --- ## #64971 — Dennis Clarke — 2013-01-15T20:05:13+00:00 URL: https://externals.io/message/64963#64971 · In reply to: #64969 > > […] 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. > > […] > > > […] > generally invoked when building PHP. configure claims otherwise. > > […] > the > > […] 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 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 and Alexandre Duret-Lutz . 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 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: . General help using GNU software: . E-mail bug reports to: . Be sure to include the word ``sed'' somewhere in the ``Subject:'' 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 ... --- ## #64972 — Dennis Clarke — 2013-01-15T20:09:42+00:00 URL: https://externals.io/message/64963#64972 · In reply to: #64965 > 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 --- ## #64991 — Christopher Jones — 2013-01-16T03:28:19+00:00 URL: https://externals.io/message/64963#64991 · In reply to: #64972 > > > […] > > 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 --- ## #64992 — Ferenc Kovacs — 2013-01-16T08:40:57+00:00 URL: https://externals.io/message/64963#64992 · In reply to: #64971 On Tue, Jan 15, 2013 at 9:05 PM, Dennis Clarke wrote: > > > […] > > 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. > > > […] > > configure claims otherwise. > > > […] > > 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. > > > […] > > 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 --- ## #64995 — Dennis Clarke — 2013-01-16T18:48:14+00:00 URL: https://externals.io/message/64963#64995 · In reply to: #64991 > > > […] > > 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 --- ## #64996 — Dennis Clarke — 2013-01-16T18:52:16+00:00 URL: https://externals.io/message/64963#64996 · In reply to: #64992 > > […] > 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