PHP 7 on Arch Linux

I have been working on PHP 7 packages for a while. They are available in my repository:

[php]
Server = https://repo.pierre-schmitz.com/$repo/os/$arch

Insert these lines on top of the other repository definitions in your /etc/pacman.conf
A copy of the PKGBUILDs I used to create the packages are available in my git repository.

Upstream changes

PHP 7 is possibly one of the most interesting releases since version 5 which was published over a decade ago. Besides up to twice the performance PHP now offers scalar type declarations and return types. The official migration guide lists all new features and incompatible changes.

Packaging changes

With PHP 7 I am trying to move closer to upstream defaults and be less opinionated. While this requires a more responsible configuration by the user it also eliminates some surprises. And after all this is the Arch way. As a bonus, scripts like Composer work fine with the default configuration now.

Core package changes

  • php-pear is no longer available
  • php-mssql was removed by upstream
  • php-ldap is now included in the core php package as its dependencies were already met
  • The mysql extension was dropped upstream and is no longer available

Configuration changes

  • openssl, phar and posix modules are now built in. Remove the corresponding directives from you php.ini, e.g. extension=openssl.so
  • The include_path is no longer set to /usr/share/pear by default
  • open_basedir is no longer defined. This also means that packaged scripts do not need to be put into an awkward /usr/share/webapps directory.
  • PHP-FPM does no longer provide a logrotate configuration. By default errors are logged to syslog (these will be picked up by journald).
  • FPM pool configuration is now stored in /etc/php/php-fpm.d by default.
  • The upstream FPM service file is now installed which does not include PrivateTmp=true.

Third party extensions

We offer a few PHP modules that are maintained by third parties and are not part of the PHP source distribution. So far only modules that are in active development were able to provide updated versions. This means we have to drop most of these PHP extensions, especially those that might be considered dead.

The following list provides an overview of modules I gathered so far. It is possible we could re-upload updated packages once upstream provides us with compatible versions.

Package Status Solution
graphviz incompatible remove PHP bindings
php-apcu compatible update to version 5
php-geoip incompatible remove package
php-memcache incompatible remove package, project seems dead
php-memcached incompatible remove package, move back when upstream version is available
php-mongo incompatible remove package, superseded by the mongodb driver
php-xcache incompatible remove package, project seems dead
uwsgi-plugin-php incompatible remove PHP support, upstream update seems possible
xdebug compatible update to latest release candidate of version 2.4

In addition to this I will introduce a new module called php-apc-bc which will provide the legacy apc_ function for use with the APCu extension. Before version 5 this feature was provided by APCu itself.

Testing in Production

While I have been working on PHP 7 for months now one really only sees how it performs when put into production. So a few days ago I started running all services at archlinux.de (this also includes this very blog) with that latest version of PHP.

So far its running fine. The update went smoother than expected and the needed configuration changes were close to nonexistent.

There are some regular but very few core dumps produced by php-fpm. These did not result in 5xx server responses though and I assume that they are related to shutting down fpm workers. It should be investigated but it does not seem critical.

Before updating I had to make two small source code changes:

  • Engine errors are now of the type \Error. \Error and \Exception implement the \Throwable interface. So I had to adjust a type hint, or in this case remove it so it would also work in PHP 5.6.
  • The return type of the \SessionHandlerInterface are now enforced. If you return anything other than a string in your custom session handler the operation will fail.

Your Feedback

Now it is your turn. The packages provided in my repository are ready and I will ensure an upgrade path once the updated packages are available in the [extra] repository. I do not plan to hold them back for very long but I’d like to get some feedback first. After all it is a major update, we drop a lot of extensions and compatibility with many scripts out there is unknown.

Try these packages, test your own code and send me your feedback and suggestions.

21 thoughts on “PHP 7 on Arch Linux

  1. Nice thank you for the update. I had no big trouble adjusting php-fpm and php configs so everything is working fine now. Unfortunately I had to get php7-pear from the AUR, so maybe you could package this as well?
    Best regards,
    Jonas

    • Thanks for testing. It seems everybody in the PHP community moved over to Composer. How exactly do you use PEAR? I guess if there is enough demand and valid use cases it can be added. At least it should be possible to maintain a standalone AUR package.

        • This seems to work fine without pear. It even has composer written all over it. Note that composer is able to install PEAR libraries into its vendor folder.

        • I don’t see how it requires PEAR. The line suggested under “Usage” works fine without it:
          composer create-project drupal-composer/drupal-project:8.x-dev some-dir –stability dev –no-interaction

          There also is no mention of PEAR anywhere on that page.

        • Roundcube does not really depend on PEAR (the package manager). In fact they also moved to composer. They provide a complete tar which includes all its dependencies.

          The package in [community] actually depends on PEAR. I have contacted the maintainer about this and hope these unnecessary dependencies can be removed.

          • UPDATE: roundcubemail in [extra] no longer depends on PEAR and all pear-* packages have been removed from the repository.

            This means there are currently no packages that require php-pear.

  2. Thank you for your efforts! Everything seems to be working great after a painless upgrade.

    The only thing I would suggest is an post-update message for the ‘php-apache’ package, something like this:
    “If you are using Apache with libphp, update your httpd.conf to use libphp7”

  3. Thanks for your effort. I’m trying to setup my development enviroment using multithreaded apache. But it complains that libphp7.so is not compiled with multithreading support. Is there a possibility to add it to the repository? Apart from my issues it’s pain free to install 🙂

  4. Thanks, Pierre. Your continued great work is much appreciated. I was able to upgrade to PHP7 using your instructions, with no major issues.

  5. there is some problems with xdebug…

    gru 24 17:51:44 arch kernel: php-fpm[7697]: segfault at 11 ip 00007f97b9a0ef42 sp 00007ffcc2852780 error 4 in xdebug.so[7f97b99e4000+3a000]
    gru 24 17:51:44 arch php-fpm[5248]: [WARNING] [pool www] child 7697 exited on signal 11 (SIGSEGV - core dumped) after 198.148685 seconds from start
    gru 24 17:51:44 arch php-fpm[5248]: [NOTICE] [pool www] child 8233 started
    gru 24 17:51:44 arch systemd-coredump[8232]: Process 7697 (php-fpm) of user 1000 dumped core.
                                                 
                                                 Stack trace of thread 7697:
                                                 #0  0x00007f97b9a0ef42 xdebug_var_export_xml_node (xdebug.so)
                                                 #1  0x00007f97b9a0ff25 xdebug_get_zval_value_xml_node_ex (xdebug.so)
                                                 #2  0x00007f97b99ff9bf n/a (xdebug.so)
                                                 #3  0x00007f97b9a01d12 n/a (xdebug.so)
                                                 #4  0x00007f97b99fec67 n/a (xdebug.so)
                                                 #5  0x00007f97b9a02b8d xdebug_dbgp_breakpoint (xdebug.so)
                                                 #6  0x00007f97b99f353f xdebug_statement_call (xdebug.so)
                                                 #7  0x000000000067d432 zend_llist_apply_with_argument (php-fpm)
                                                 #8  0x000000000070f6b6 n/a (php-fpm)
                                                 #9  0x00000000006ca34b execute_ex (php-fpm)
                                                 #10 0x00007f97b99f39ef xdebug_execute_ex (xdebug.so)
                                                 #11 0x000000000071a58c n/a (php-fpm)
                                                 #12 0x00000000006ca34b execute_ex (php-fpm)
                                                 #13 0x00007f97b99f39ef xdebug_execute_ex (xdebug.so)
                                                 #14 0x000000000071d1c7 zend_execute (php-fpm)
                                                 #15 0x0000000000689503 zend_execute_scripts (php-fpm)
                                                 #16 0x0000000000629fc0 php_execute_script (php-fpm)
                                                 #17 0x0000000000433b12 n/a (php-fpm)
                                                 #18 0x00007f97bb42a610 __libc_start_main (libc.so.6)
                                                 #19 0x0000000000434949 _start (php-fpm)
  6. Runs fine as far as i can tell, tested some cli scripts, composer and websites with it, no issues so far. XDebug works fine for me too.

    Thanks for your work!

Leave a Reply

Your email address will not be published. Required fields are marked *