/********** For the sake of getting this issue looked into I am going to cross post * to two maillists. Maybe the PHP folks see the issue and will reply with an * update. Who knows. */
Original message to the bison mailist : > Le 15 janv. 2013 à 00:19, Dennis Clarke <dcla...@blastwave.org> a > écrit : > > > Dear bison folks : > > Hi! > > > This is not really a bug but rather a question. I recently saw that > PHP had been updated to 5.4.10 and I decided to try building it. 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? I will look for some sort of reasonable dev list for > > the php folks as it would be a good idea to get some input from them. > > Any reply from the bison team would be appreciated also. > [ from Akim Demaille on bison maillist ] > I have no idea why this is checked/displayed. Maintaining backward > compatibility is certainly a nice feature, but supporting > 1.28 for instance seems completely pointless. Actually, it > also means that they use no recent feature, which is sad. > > On the other end of the spectrum, I have no idea why they > want to check the version this way. I am not aware of bugs > in 2.7 for instance, yet I know issues 2.7 solves over 2.6.5, > which itself is superior to 2.6.2. > > Really, I'd be happy to know more about this. Well there are other issues also as I have yet to see PHP build cleanly on Solaris 10. Every build of PHP going back a number of revs always results in "FAILED TEST SUMMARY" at the end of the testsuite as well as "You may have found a problem in PHP." My configure line looks like : ./configure --with-apxs2=/usr/local/bin/apxs --with-mysql=/opt/mysql/mysql \ --with-libxml-dir=/usr/local --sysconfdir=/usr/local/etc \ --includedir=/usr/local/include --libdir=/usr/local/lib \ --libexecdir=/usr/local/libexec --localstatedir=/usr/local/var/php \ --mandir=/usr/share/man --infodir=/usr/local/share \ --cache-file=../php-5.4.10_SunOS5.10_sparcv9.config.cache --disable-debug \ --with-pic --with-bz2 --with-gettext --with-gmp --with-iconv --with-openssl \ --with-zlib --enable-ftp --enable-sockets --without-kerberos \ --enable-calendar --enable-xml --disable-json --with-curl=/usr/local \ --enable-posix Where apache 2.4.3 is up and running and has been for a while now as well as a host of other GNU tools that will not get installed unless they pass their own testsuite flawlessly. To get that to happen I did need to contribute back to flex and a few others but the work is worth it. What then will it take to get PHP to compile from a release tarball ? Shall I create a clean Solaris zone sandbox first and test a build there with Oracle Solaris Studio 12.3 ? Really I would like to hear from the PHP folks on this as it seems as if PHP is quite fragile or perhaps simply mysterious. Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php