Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Non-conflicting PHP 5 and 7 builds »

Non-conflicting PHP 5 and 7 builds

php.internals

Jordan Gigov

10 years ago
Most developers who hope to move a site to PHP 7 will still have to maintain PHP 5 sites for a long time, requiring the presence of both. However, building either one, even with the `--program-suffix` configuration option still overwrites some files, like phpize and all the headers in ${prefix}/includes/. It took me a week to solve this problem for myself and everyone else in our company, but I have proper working patches for it now. They have not been submitted as pull requests yet, because I first want to hear what you think of them. Here are the links: https://github.com/coladict/php-src/tree/php5-migration https://github.com/coladict/php-src/tree/php7-migration These change the install destinations like so: ${prefix}/bin/php => ${prefix}/bin/php[5 or 7] ${prefix}/bin/phpize => ${prefix}/bin/php[5 or 7]ize ${prefix}/bin/php-config => ${prefix}/bin/php[5 or 7]-config ${prefix}/bin/php-cgi => ${prefix}/bin/php[5 or 7]-cgi ${prefix}/bin/phpdbg => ${prefix}/bin/php[5 or 7]dbg ${prefix}/bin/phar => ${prefix}/bin/phar[5 or 7] ${prefix}/bin/phar.phar => ${prefix}/bin/phar[5 or 7].phar I have also added a "install-alternatives" make target that creates soft links to the legacy locations. In systems that have "update-alternatives" like Debian, Ubuntu or Fedora it uses it to generate the links, otherwise it falls-back to "ln -s". In addition these both contain fixes for gd, gmp and ldap extensions that fail to build under Ubuntu 16.04. Tested under Docker containers of ubuntu:xenial, fedora and dock0/arch (Archlinux). Additional configure options used when testing: --with-pic --enable-cli --enable-phpdbg --disable-fpm --with-apxs2=no --build=x86_64-linux-gnu --with-layout=GNU I don't know why automatic detection always yields x86_64-unknown-linux-gnu for build under Ubuntu, but that's not particular to PHP. Shared extensions that are also built and loaded without error during the testing: mbstring gd mysqlnd mysqli pdo_mysql curl gettext pgsql pdo_pgsql xmlrpc bz2 xsl enchant interbase pdo_firebird mcrypt pspell gmp ldap readline recode tidy Making separately building mysqlnd work as shared should really come with it's own instructions. I had to use this complicated stuff ./configure --build=x86_64-linux-gnu --with-pic --enable-mysqlnd \ CFLAGS="-I/usr/include/openssl -I$(dirname $(dirname $(pwd))) -DCOMPILE_DL_MYSQLND -DMYSQLND_SSL_SUPPORTED -DMYSQLND_COMPRESSION_WANTED -DMYSQLND_COMPRESSION_ENABLED -DMYSQLND_HAVE_SSL" \ PHP_OPENSSL="/usr/local /usr" --with-libdir=lib/x86_64-linux-gnu Under Fedora that libdir option changes to --with-libdir=lib64

Andreas Heigl

10 years ago
Hi Jordan. Great Idea. There are just a few questions I have: * Is it possible to extend that system also to minor and patch versions? * What effect has that on docker or vagrant systems? Especially on maintainability of up-to-date versions that will have to symlink the current version to a new binary with every version? * what effect would that have on non-release versions? For our development it has been intresting to be able to switch between different minor and patch-versions of PHP so we use vagrant or docker for different projects depending on the PHP-Version available on the productive servers. That can then also include extensions and so on. Alternatively I've used the prefix to distinguish between the versions and then created symlinks to the binaries inside a bin-folder. When that was necessary at all, as f.e. php-fpm can be called right inside the respective prefiexed folder... And then there's also phpenv which took rbenv as a model. Cheers Andreas Am 02.09.16 um 14:28 schrieb Jordan Gigov:
> Most developers who hope to move a site to PHP 7 will still have to > maintain PHP 5 sites for a long time, requiring the presence of both. > However, building either one, even with the `--program-suffix` > configuration option still overwrites some files, like phpize and all the > headers in ${prefix}/includes/. > > It took me a week to solve this problem for myself and everyone else in our > company, but I have proper working patches for it now. > They have not been submitted as pull requests yet, because I first want to > hear what you think of them. > > Here are the links: > > https://github.com/coladict/php-src/tree/php5-migration > https://github.com/coladict/php-src/tree/php7-migration > > These change the install destinations like so: > ${prefix}/bin/php => ${prefix}/bin/php[5 or 7] > ${prefix}/bin/phpize => ${prefix}/bin/php[5 or 7]ize > ${prefix}/bin/php-config => ${prefix}/bin/php[5 or 7]-config > ${prefix}/bin/php-cgi => ${prefix}/bin/php[5 or 7]-cgi > ${prefix}/bin/phpdbg => ${prefix}/bin/php[5 or 7]dbg > ${prefix}/bin/phar => ${prefix}/bin/phar[5 or 7] > ${prefix}/bin/phar.phar => ${prefix}/bin/phar[5 or 7].phar > > I have also added a "install-alternatives" make target that creates soft > links to the legacy locations. > In systems that have "update-alternatives" like Debian, Ubuntu or Fedora it > uses it to generate the links, otherwise it falls-back to "ln -s". > > In addition these both contain fixes for gd, gmp and ldap extensions that > fail to build under Ubuntu 16.04. > > Tested under Docker containers of ubuntu:xenial, fedora and dock0/arch > (Archlinux). > Additional configure options used when testing: > --with-pic --enable-cli --enable-phpdbg --disable-fpm --with-apxs2=no > --build=x86_64-linux-gnu --with-layout=GNU > > I don't know why automatic detection always yields x86_64-unknown-linux-gnu > for build under Ubuntu, but that's not particular to PHP. > > Shared extensions that are also built and loaded without error during the > testing: > mbstring gd mysqlnd mysqli pdo_mysql curl gettext pgsql pdo_pgsql xmlrpc bz2 > xsl enchant interbase pdo_firebird mcrypt pspell gmp ldap readline recode > tidy > > > Making separately building mysqlnd work as shared should really come with > it's own instructions. I had to use this complicated stuff > ./configure --build=x86_64-linux-gnu --with-pic --enable-mysqlnd \ > CFLAGS="-I/usr/include/openssl -I$(dirname $(dirname $(pwd))) > -DCOMPILE_DL_MYSQLND -DMYSQLND_SSL_SUPPORTED -DMYSQLND_COMPRESSION_WANTED > -DMYSQLND_COMPRESSION_ENABLED -DMYSQLND_HAVE_SSL" \ > PHP_OPENSSL="/usr/local /usr" --with-libdir=lib/x86_64-linux-gnu > > Under Fedora that libdir option changes to --with-libdir=lib64 >
-- ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +---------------------------------------------------------------------+ | http://hei.gl/root-ca | +---------------------------------------------------------------------+

Jordan Gigov

10 years ago
I'll try to answer as best I can.
> Is it possible to extend that system also to minor and patch versions?
Extending it to allow minor versions would require some changes in "scripts/phpize.m4" and "scripts/phpize.in" to make that information available to extensions, without having to parse the version string. It would probably be better to make them maintain information about "--program-prefix" and "--program-suffix", which would also need to be added to the "phpincludedir" variable. phpincludedir is maintained in four locations in "scripts/Makefile.frag", "ext/pdo/Makefile.frag", "scripts/php-config.in" and "scripts/phpize.in". That should really be unified to one variable some day. Using "--program-prefix" and "--program-suffix" would then ensure no conflict ever arises if say, you want to change something in the installed headers and you don't feel safe about overwriting them for the major version.
> What effect has that on docker or vagrant systems? Especially on
maintainability of up-to-date versions that will have to symlink the current version to a new binary with every version? I don't know what docker/vagrant container set-up you have in mind, but generally if the system has "update-alternatives", you will be able to use it to switch all of the symlinks from the default paths to point to the particular build. If it doesn't, so long as you keep that Makefile intact you can use "make install-alternatives" to overwrite all the symlinks. There are no provided symlink alternatives for an Apache module, nor an FPM unix socket, as there isn't a default one defined or recommended.
> what effect would that have on non-release versions?
The "install-alternatives" target would have to be added last to the defaults to ensure backwards compatibility for unsuspecting builders. Currently it is not, and must be specified when calling "make". 2016-09-02 15:47 GMT+03:00 Andreas Heigl <andreas@heigl.org>:

Diogo Galvão

10 years ago
On Fri, Sep 2, 2016 at 9:28 AM, Jordan Gigov <coladict@gmail.com> wrote:
> Most developers who hope to move a site to PHP 7 will still have to > maintain PHP 5 sites for a long time, requiring the presence of both. > However, building either one, even with the `--program-suffix` > configuration option still overwrites some files, like phpize and all the > headers in ${prefix}/includes/. > > It took me a week to solve this problem for myself and everyone else in our > company, but I have proper working patches for it now. > They have not been submitted as pull requests yet, because I first want to > hear what you think of them. > > Here are the links: > > https://github.com/coladict/php-src/tree/php5-migration > https://github.com/coladict/php-src/tree/php7-migration >
Hi, Jordan. I've also been manually keeping different PHP versions installed, but I took another approach: each version has its own prefix in /opt. /opt/php/php-5.6.25 /opt/php/php-7.0.10 And each x.y version is a symlink to the latest release I've tried: /opt/php/php-5.6 -> /opt/php/php-5.6.25 /opt/php/php-7.0 -> /opt/php/php-7.0.10 On some servers and on my own desktop I also keep symlinks in /usr/local/bin to their respective binaries in /opt. I'm mentioning this because it seems to work and doesn't require any change on PHP itself. Unless I'm missing something. This is the script I use to fetch and build new versions: https://github.com/garotosopa/misterbin

Levi Morrison

10 years ago
On Fri, Sep 2, 2016 at 6:28 AM, Jordan Gigov <coladict@gmail.com> wrote:
> Most developers who hope to move a site to PHP 7 will still have to > maintain PHP 5 sites for a long time, requiring the presence of both. > However, building either one, even with the `--program-suffix` > configuration option still overwrites some files, like phpize and all the > headers in ${prefix}/includes/. > > It took me a week to solve this problem for myself and everyone else in our > company, but I have proper working patches for it now. > They have not been submitted as pull requests yet, because I first want to > hear what you think of them. > > Here are the links: > > https://github.com/coladict/php-src/tree/php5-migration > https://github.com/coladict/php-src/tree/php7-migration > > These change the install destinations like so: > ${prefix}/bin/php => ${prefix}/bin/php[5 or 7] > ${prefix}/bin/phpize => ${prefix}/bin/php[5 or 7]ize > ${prefix}/bin/php-config => ${prefix}/bin/php[5 or 7]-config > ${prefix}/bin/php-cgi => ${prefix}/bin/php[5 or 7]-cgi > ${prefix}/bin/phpdbg => ${prefix}/bin/php[5 or 7]dbg > ${prefix}/bin/phar => ${prefix}/bin/phar[5 or 7] > ${prefix}/bin/phar.phar => ${prefix}/bin/phar[5 or 7].phar > > I have also added a "install-alternatives" make target that creates soft > links to the legacy locations. > In systems that have "update-alternatives" like Debian, Ubuntu or Fedora it > uses it to generate the links, otherwise it falls-back to "ln -s". > > In addition these both contain fixes for gd, gmp and ldap extensions that > fail to build under Ubuntu 16.04. > > Tested under Docker containers of ubuntu:xenial, fedora and dock0/arch > (Archlinux). > Additional configure options used when testing: > --with-pic --enable-cli --enable-phpdbg --disable-fpm --with-apxs2=no > --build=x86_64-linux-gnu --with-layout=GNU > > I don't know why automatic detection always yields x86_64-unknown-linux-gnu > for build under Ubuntu, but that's not particular to PHP. > > Shared extensions that are also built and loaded without error during the > testing: > mbstring gd mysqlnd mysqli pdo_mysql curl gettext pgsql pdo_pgsql xmlrpc bz2 > xsl enchant interbase pdo_firebird mcrypt pspell gmp ldap readline recode > tidy > > > Making separately building mysqlnd work as shared should really come with > it's own instructions. I had to use this complicated stuff > ./configure --build=x86_64-linux-gnu --with-pic --enable-mysqlnd \ > CFLAGS="-I/usr/include/openssl -I$(dirname $(dirname $(pwd))) > -DCOMPILE_DL_MYSQLND -DMYSQLND_SSL_SUPPORTED -DMYSQLND_COMPRESSION_WANTED > -DMYSQLND_COMPRESSION_ENABLED -DMYSQLND_HAVE_SSL" \ > PHP_OPENSSL="/usr/local /usr" --with-libdir=lib/x86_64-linux-gnu > > Under Fedora that libdir option changes to --with-libdir=lib64
The issue is that you are writing to the same prefix. Just write them to different prefixes and reference them separately. This is not a unique-to-php situation. At work we maintain many different simultaneous versions of Python, for example. With that said it looks like the program suffixes are broken. If --program-suffix=7 is set then I'd expect php7, phpize7 (or php7ize, don't really care), etc.

Jordan Gigov

10 years ago
I can see your argument for using prefix, but that would not provide a solution to package maintainers who may want to give their users a choice. I was recently surprised when upgrading from Ubuntu 14 to 16 that it replaced PHP 5 with 7 entirely. They were forced into choosing between the two at a time when most developers will have to maintain both versions for several more years for different projects. And what do you mean --program-suffix is broken? What do you get and expect to get? With or without my changes it seems work as intended. 2016-09-02 18:28 GMT+03:00 Levi Morrison <levim@php.net>:

Davey

10 years ago
Jordan, This was a choice they made, yet the author of the Debian/Ubuntu packages has side-by-side installable versions from 5.5-7.1 in his own PPA: https://launchpad.net/~ondrej/+archive/ubuntu/php It's not only currently feasible, it has been done, the _project_ chose not to do it. - Davey On Sun, Sep 4, 2016 at 12:57 AM, Jordan Gigov <coladict@gmail.com> wrote: