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
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-migrationThese 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].pharI 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=GNUI 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
tidyMaking 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-gnuUnder 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 |
+---------------------------------------------------------------------+
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:
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
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:
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-migrationThese 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].pharI 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=GNUI 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
tidyMaking 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-gnuUnder 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.
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:
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,
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
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:
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.