Package Base Details: php71

Git Clone URL: https://aur.archlinux.org/php71.git (read-only)
Keywords: 7.1 php
Submitter: Synthead
Maintainer: wget
Last Packager: wget
Votes: 10
Popularity: 0.031844
First Submitted: 2018-03-26 18:04
Last Updated: 2019-11-03 19:03

Pinned Comments

wget commented on 2019-02-11 11:49

This package makes use of GPG keys for integrity verification. Here are the PGP keys you need to import (if you trust them):

$ gpg --recv-keys A917B1ECDA84AEC2B568FED6F50ABC807BD5DCD0 528995BFEDFBA7191D46839EF9BA0ADA31CBD89E 1729F83938DA44E27BA0F4D3DBDB397470D12172

Receiving GPG keys might fail with the following error message: $ gpg: keyserver receive failed: Connection refused. If this happens, just check your DNS or use other ones.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 Next › Last »

gabrielozaki commented on 2018-04-19 13:57

Hi guys, works for me:

1) remove all php71 packages

2) Install this package(don't worry, this package come with a lot of another packages, like gd,mysql,pgsql...)

3) softlink the module and conf:

ln -s /etc/httpd/modules/php71.so /etc/httpd/modules/libphp7.so

ln -s /etc/httpd/conf/extra/php71_module.conf /etc/httpd/conf/extra/php7_module.conf

4) add this line to <directory "your_webroot_folder"=""> of file /etc/httpd/conf/httpd.conf :</directory>

DirectoryIndex index.php

elimpfor commented on 2018-04-10 20:12

Wow. Upgraded from php71-7.1.14 to 7.1.16 and it completely broke everything. For some reason libphp7.so changed to php71.so. Then, when manually modifying httpd.conf so apache can start again, php is not reading /etc/php/php.ini and saying the modules are missing etc... Glad I have the pkg/cache to revert...

betarepeating commented on 2018-04-06 23:14

Updated to the latest apache (apache-2.4.33) and suddenly apache would no longer start. I had same error as FrederickZh. Changing the name of the module did not fix it, still got "Can't locate API module structure".

What is my httpd.conf line entry supposed to look like? I changed it to point to the /opt directory but it still did not work.

FrederickZh commented on 2018-04-06 02:56

I have both the PHP in the official repo and this one installed and I do prefer having this one in /opt instead of /usr. Installing different versions of a single application all into /usr seems to be a more Ubuntu thing to me actually... I don't have php70 or php56 in my system but I wonder how they maintain the naming consistency as php in official repo never takes multi-version into consideration?

But perhaps we could flatten the directory structure a bit? The /opt/usr tends to be somewhat redundant imo.

Edit: And the naming of php71-apache... Official one is using libphp7.so, so maybe "libphp71.so" is a better choice here?

Edit 2: The apache module is called "php7_module" instead of "php71_module" as shown in php71_module.conf. Using "php71_module" gave me an error of "httpd: Syntax error on line 190 of /etc/httpd/conf/httpd.conf: Can't locate API module structure `php71_module' in file /etc/httpd/modules/php71.so: /etc/httpd/modules/php71.so: undefined symbol: php71_module".

lilmike commented on 2018-04-05 15:22

Patch added to fix intl compilation. Let me know if there are any issues.

Synthead commented on 2018-04-04 20:50

@schlmm: I saw where the other packages were configuring and putting their files, and I actually like it a little better in /opt. This naturally keeps the conflicts away without fussing with patches or renaming things (i.e. /etc/php/php.ini, for example). If someone familiar with Linux was told to troubleshoot a problem with an additional PHP 7.1 installation and they saw it in /opt, they'd know exactly what's going on. These are just my personal, subjective thoughts, though. What do you think?

Also, /usr/lib/systemd/system/php71-fpm.service is included in php71-fpm, which is built in this PKGBUILD. Is there something additional you're looking to have included?

@arakmar and @zack6849: I updated the package to build against the latest ICU. Thanks!

@muhviehstarr: Honestly, I don't really like the idea of a /etc/profile.d/ entry because it makes the php binary implicit. With your example, "php" would always refer to the 7.1 binary, even when the upstream php package is installed. This means that other applications that use the php binary without an absolute path would unknowingly execute the 7.1 version. A bit of a gotcha. Instead, I think the right thing to do is to export $PATH or use an absolute path for the specific use cases where PHP 7.1 is necessary. What are your thoughts?

zack6849 commented on 2018-04-04 20:05

Doesn't build properly for me, get compiler errors, is this package still maintained?

lilmike commented on 2018-04-03 13:29

Unfortunately that seems to be a conflict between php and the new version of the required library on arch. I've opened a bug on php.net, and will definitely update the package with any patches as I receive them. Just hold tight!

-Michael.

XenGi commented on 2018-04-03 13:20

The new update to 7.1.16 doesn't compile anymore. Here's the output: https://gist.github.com/XenGi/fd6050a915fcc002b2f2214058557d51

Some UnicodeError and other stuff.

muhviehstarr commented on 2018-04-02 16:45

maybe you should add bin links or add /opt/php71/usr/bin to PATH via an /etc/profile.d/ entry like this:

/etc/profile.d/php71.sh

!/bin/sh

export PATH=$PATH:/opt/php71/usr/bin

this will avoid fail updates like nextcloud which use the php binary for updates for users that only have installed php71