Homebrew-core: php: Install PECL Modules for different PHP Versions

Created on 3 Apr 2018  路  43Comments  路  Source: Homebrew/homebrew-core

With the deprecation of homebrew/php all modules which are not within the default distribution should be installed through pecl. To ease the assumptions the pecl configure and compile will make the default path, where to install pecl modules to, is /usr/local/lib/php/pecl.

For singular installations so far so good. But if I have multiple Installations (because of legacy applications wich have to be dev-maintaned) we now have a serious clash of PECL module/installed information.

All Versions php, [email protected], [email protected] will link to /usr/local/lib/php/pecl -- Now if I install things like xdebug with php 7.2 it will will be incompatible with php 5.6 or at the very last the file for the php 5.6 API will simply not exist. A simple pecl install xdebug in the respective versions will just tell you that xdebug is already installed... But not for the current active Version (e.G. install xdebug with php7.2 then switch PATH exports to php5.6 and try to install xdebug with pecl...)

This may be fixed through running pecl install --force xdebug on each version to get it compiled for their respective API Version. But it seems like a non-fluid non-obvious solution and feels more likely to be hacky and lead to issues like the one I opened with this, which will have to be answered all the time a new user tries to get that particular problem solved.

I guess we could either fix that problem through a adjusted pecl configuration, so each PHP will get its own pecl directory (which may or may not be pita and was therefore not added in the initial port) or we add this particular information to the caveats of a brew php installation.

outdated php

Most helpful comment

I really like the old way of install php, that allows me to customize php, but now brew just force me to use the default config and no way to customize.

All 43 comments

It's related but in the mentioned issue its all about PEAR. This issue is about PECL -- But they are similar in regard of semi-global folders for non globalizable content because of multi-version compatibility constraints.

@kabel @javian thoughts?

Since php uses the ABI version as part of the path /usr/local/lib/php/pecl/20160303 the idea was that we wouldn't need to version it for the PHP version at least for the storage of the extensions. I discovered some issues with my machine but it might be related to me having some old configs but I'll check an update here.

Update:
After I removed my old php config and installed the one that came with the new [email protected] formula it loads everything as it should from the right location.

Just to update on my last post it seems that the following section in the php config is different between the new and old php formulas

; Directory in which the loadable extensions (modules) reside.
; http://php.net/extension-dir
extension_dir = "/usr/local/lib/php/pecl/20160303"

In the previous formulas this variable wasn't set meaning that it will read the default directory which is not what we want with the new formulas.

and I think there is another problem, trying to install php by brew install php gets php72, that's fine for me, but everytime I try to install, it force me to install apache, and build from source.

I personally hate to use apache as my dev web server, also seems there is no way to build a threaded php version?

I really like the old way of install php, that allows me to customize php, but now brew just force me to use the default config and no way to customize.

You can always customise the formula in a custom tap. As for the configuration, that hasn't really changed with the migration.

Threaded PHP hasn't ever been supported by homebrew and apache is required to build the apache extension, which you don't _have_ to use.

@javian So what if you install php, [email protected], [email protected] and [email protected] on the same machine. Are you able to install this via pecl, for example xdebug, for all 3 instances without any problems (or force flags)?

  • 7.x will need xdebug-2.6.0
  • 5.x will need xdebug-2.5.5

It's especially about multi version installations, where I need all of them. Thing is pecl seems to store meta about already installed extensions. So the pecl of 7.1 and 5.6 will think it already has xdebug installed, at least for me. It could be that I did not pristine reinstalled my whole brew on my mac (because of productive reasons as it's a workday, I cleaned /usr/local/etc/php and reinstalled all php versions though...)

Will this run just fine for you?

brew install php [email protected] [email protected] [email protected]

# as php is globally linked
pecl install xdebug-2.6.0

# install xdeubg for all other instances/APIs
export PATH="/usr/local/opt/[email protected]/bin:$PATH"
export PATH="/usr/local/opt/[email protected]/sbin:$PATH"
# this will fails for me as pecl thinks its already installed, but not for the current exportet API
pecl install xdebug-2.5.5

export PATH="/usr/local/opt/[email protected]/bin:$PATH"
export PATH="/usr/local/opt/[email protected]/sbin:$PATH"
# this will fail too
pecl install xdebug-2.6.0

export PATH="/usr/local/opt/[email protected]/bin:$PATH"
export PATH="/usr/local/opt/[email protected]/sbin:$PATH"
# this will fail too
pecl install xdebug-2.6.0

##
## The failing pecl installs can be forced through 'pecl install --force xdebug-x.y.z'
## Where as x.y.z is the version of xdebug you want to install.
## But the final solution of the hombrew team sould be a better one as this feels hacky ;)
##

EDITED 04.04.18 20:17 for clarification in my shell script block above, to clarify thats not a fix but a problem and to show a hacky solution. Both are also mentioned in the opening post, but may not be visible at first glance, hidden in my wall of text trying to describe the problem.

/usr/local/opt/[email protected]/bin/pecl install xdebug-2.5.5
/usr/local/bin/pecl install xdebug-2.6.0

Would probably work better/easier.

EDIT: Changed path because of upgrade safety as mentioned below.

@SMillerDev /usr/local/Cellar/[email protected]/5.6.35 is not update safe btw.

Thats why I used the after-install caveat displayed exports which use /usr/local/opt/[email protected]. Just to illustrate that the problem exists with default/known information to a new brew user.

In my local Environment i have enable_phpxx(){} bash functions which will just set the upper exports so I can switch in a fast/defined way locally.

But the how-to-call should not be a problem here. As it should work with the exact information a user gets through the installation caveats.

I just figured exporting the entire bin directory was a bit overkill for just pecl, but if you need to switch complete environments this should work just fine.

We did run in several issues with the new update. I'm correctly that I need todo the following to install extensions like redis, imagick, ...

pecl install imagick
cd /usr/local/etc/php/7.0/conf.d
echo "extension=imagick.so" > ext-imagick.ini
echo 'extension_dir = "/usr/local/lib/php/pecl/20151012"' > 00-extension.ini
brew services restart php70

the 20151012 folder is a little bit strange but could not find any symlink to the correct version?

I'm really unhappy about this as before it was just brew install php70-imagick

It's probably easier to just change the extensions directory in php.ini

@SMillerDev but changing in the php.ini does not change that I need also create the ext-imagick.ini manually or does pecl create the ext-imagick.ini file somewhere else?

I have following issues. How to resolve them?

Failed loading /usr/local/Cellar/[email protected]/7.0.29/lib/php/20151012/xdebug.so: dlopen(/usr/local/Cellar/[email protected]/7.0.29/lib/php/20151012/xdebug.so, 9): image not found PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/opt/php70-intl/intl.so' - dlopen(/usr/local/opt/php70-intl/intl.so, 9): Library not loaded: /usr/local/opt/icu4c/lib/libicui18n.60.dylib Referenced from: /usr/local/opt/php70-intl/intl.so Reason: image not found in Unknown on line 0

Warning: PHP Startup: Unable to load dynamic library '/usr/local/opt/php70-intl/intl.so' - dlopen(/usr/local/opt/php70-intl/intl.so, 9): Library not loaded: /usr/local/opt/icu4c/lib/libicui18n.60.dylib Referenced from: /usr/local/opt/php70-intl/intl.so Reason: image not found in Unknown on line 0 PHP Warning: Module 'mcrypt' already loaded in Unknown on line 0

Warning: Module 'mcrypt' already loaded in Unknown on line 0 PHP 7.0.29 (cli) (built: Apr 3 2018 16:53:44) ( NTS ) Copyright (c) 1997-2017 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies with Zend OPcache v7.0.29, Copyright (c) 1999-2017, by Zend Technologies with Xdebug v2.6.0, Copyright (c) 2002-2018, by Derick Rethans

@alexander-schranz The PECL installation process will prepend the needed extension= or zend_extension= to the correct php.ini. Thats why this issue is all about getting the tools, PHP has for managing the stuff, in this case the PECL CLI, to work as if there is only the current active version. Which just does not work correctly for multiple php version installed on the system which may need the same extension installed.

The whole ext-*.ini thing was about how the bundling of the homebrew/php repository worked.

@kilis This does not contribute to this issue and is not related in any way. Please clean your installation first (uninstall and untap all homebrew/php packages, remove all old configs in /usr/local/etc/php and reinstall php from the homebrew/core repository to regenerate the configuration files). The intl module is also already compiled in to the php distributions provided by the homebrew/core repository, as many others too (see php -m).

@ilovezfs could this issue be locked for contributors and the issue creator so it won't get spammed with other, maybe related but not, issues? It may get off-the-point I try to make otherwise.

@kilis - I had the same issue and stumbled here. You don't need to install these as extra packages, like php7x-mcrypt / php7x-intl as they now get installed automatically. The only one I had to run separately was:

"pecl install xdebug"

...lilke @Blackskyliner says, you just need to remove the old refs and all should be okay. I only realised this when I ran "php -m" in the console and saw that all the packages I used to install manually were all ready there.

@Blackskyliner Thanks worked

I'm having trouble with...

$ pecl install ssh2
pecl/ssh2 requires PHP (version >= 4.0.0, version <= 6.0.0), installed version is 7.2.4
No valid packages found
install failed

pecl install ssh2-alpha

I am in the same situation: I need multiple PHP versions (5.4, 5.6, 7.0, 7.1 and 7.2) but, since last update, I can not make xdebug to work. I have removed and reinstalled all PHP and Apache packages, and reinstalled it all, starting with PHP 7.2

So far, installing it was fine, as it is the current version. And I could install xdebug with pecl:

pecl install xdebug

But then I tried to install PHP.56 and, though the installation was fine, I could not install xdebug.

I unlinked PHP 7.2 and linked PHP 5.6, and I have tried what @Blackskyliner suggested:

export PATH="/usr/local/opt/[email protected]/bin:$PATH"
export PATH="/usr/local/opt/[email protected]/sbin:$PATH"
pecl install xdebug-2.5.5

And what @SMillerDev suggested too:

/usr/local/opt/[email protected]/bin/pecl install xdebug-2.5.5

But, in both cases, with the same failed result:

pecl/xdebug is already installed and is newer than detected released version 2.5.5
install failed

Is there any option to get it working? Have any of you got it?

Thanks!

I'm having a problem installing intl via pecl. Anyone else having problems with that?
[email protected] and I have icu4c installed too, I've even tried to force link it using homebrew and using --with-icu-dir=...

Intl is included in the php binary.

@rubenrubiob try removing the old version first.

Intl is included in the PHP binary.

Hmm, somehow I must have run an old binary... I'll have another go.

@rubenrubiob did you also remove the php config files when reinstalling ?
You can always confirm that your extension dir is correct by issuing php-config --extension-dir and making sure it points to something like /usr/local/Cellar/php/7.2.4/pecl/20170718 depending on the php version you are using.

It's very strange that migrated only php core. Why extensions that worked ok with homebrew-php isn't migrated to core?

@Den4ik they have no place in homebrew-core at the moment and pecl is they way to manage them and what is provided by the php community. It doesn't stop anyone from setting up a tap that accomplishes the same thing but it would require some work since the formulas are abstracted in the tap and will not work without modification.

@rubenrubiob if you read my opening post of this issue throughly: You can "fix" this with pecl install --force xdebug or in your scenario pecl install --force xdebug-2.5.5 after switching to php 5.6 -- Thats in fact the current state which _can_ mitigate the problem in a hacky way as mentioned.

EDIT: I updated my comment above, so it's more obvious in case others may also overread that part of my introduction to the problem and the description of that possible (hacky) fix.

Okay, with @Blackskyliner suggestion I got it working 鈥攕orry, I over-read it. It will have to do by the moment.

The annoying thing is to switch between PHP versions, because there are many things to change: apache configuration, linking PHP version and changing the line in .zshrc file. The switcher scripts I used to use do not work anymore.

@rubenrubiob brew-php-switcher may end up helping with that.

@ilovezfs Great! I will give it a try once it is available to install. Thank you!

Not sure if this should go here or in a separate issue...

With multiple PHP versions installed... in my case, let's just say [email protected] and [email protected] to keep things simple for the moment...

I have no trouble installing PECL extensions for multiple versions, since they go into differently versions Zend ABI folders.

But the PEAR/PECL channel info for pecl.php.net is store in the same place, which causes the following problem...

After I finished getting [email protected] working perfectly, pecl list shows all my installed extensions. After installing [email protected] and installing Xdebug only, pecl list shows only Xdebug installed.

All the extensions are still installed and function properly, but PECL/PEAR has lost track of them because the two PHP installations are overwriting each others PEAR metadata.

Note: I only have [email protected] linked. I've been doing everything with [email protected] keg-only and I never linked it.

EDIT: I think this pull request will address the issue I'm describing: https://github.com/Homebrew/homebrew-core/pull/26137

Thanks for the additional information. Yes, that's the PR we're working through.

BTW, I've updated my guide to cover handling the new Homebrew/core + PECL package installation for multiple PHP versions: https://getgrav.org/blog/macos-sierra-apache-multiple-php-versions

@rhukster the switcher script you're linking is just a copy of the script that's gonna be installed with this btw: https://github.com/Homebrew/homebrew-core/pull/26181 which is obvously on it's way to be included into homebrew.

璇烽棶濡備綍瑙e喅brew tap homebrew/dupes 鎶ョ殑锛欵rror: homebrew/dupes was deprecated. This tap is now empty as all its formulae were migrated. 瀹夎[email protected]鏍逛互鍓嶇殑php5.6鍖哄埆濂藉ぇ銆傚浣曡brew search php56鍙互鍑虹幇鎵╁睍

"With the deprecation of homebrew/php all modules which are not within the default distribution should be installed through pecl. "
I think I just threw up a little.

Would have been nice to have had a community discussion or vote about all this disruption.

Things were essentially perfect with homebrew-php. Why are we resurrecting PECL and PEAR?? Extension discover was bolstered by the php7x-extensionname formulae naming; it was easy to add/remove/update with brew update/upgrade; and php version switching was super-easy and safe.

If we're not going to use brew any longer to manage extensions, then we need to immediately create a modern replacement for PECL.

You could have had your voice heard in the PR that was started last year. We're now removing the burden of keeping all dependencies up to date from homebrew and putting them back where they belong, with the php standard, pecl.

You're more than welcome to make an rfc to replace pecl on the php internals mailing list though. Would love to see something better emerge.

A pecl replacement has been discussed upstream before and there is an RFC. Those are conversations that should continue upstream.

@SMillerDev You're right. Unfortunately, most users of brew, do not pay any attention to the development of brew. In a way, this speaks to how well brew accomplishes its mission.

Was this page helpful?
0 / 5 - 0 ratings