WP CLI errors, "Failed loading ... opcache.so" "xdebug.so" and "Warning: PHP Startup: Unable to load dynamic library ... imagick.so" code unsigned

This has been reported several different times without resolution that I can find. Those threads are mostly closed due to time limits.

So trying again.

While these seem somewhat harmless, they make working with WP CLI a pain.

This has been going on for 6 months, so it’s not really version specific. There seem to bee similar reports from Win10 users, but this is on macOS 10.15.7.

3 out of 4 of these appear to be code signing issues.

2020-11-02 at 12.07 PM

Is there any way to fix or silence these?

Have the same messeges.
Just updated to 5.9.7 - have it in both versions.
Also on Mac

Having this as well on MacBook M1.

--- app/public » wp help
Failed loading /Users/ipstenu/Library/Application Support/Local/lightning-services/php-7.4.1+14/bin/darwin/lib/php/extensions/no-debug-non-zts-20190902/opcache.so:  dlopen(/Users/ipstenu/Library/Application Support/Local/lightning-services/php-7.4.1+14/bin/darwin/lib/php/extensions/no-debug-non-zts-20190902/opcache.so, 9): no suitable image found.  Did find:
	/Users/ipstenu/Library/Application Support/Local/lightning-services/php-7.4.1+14/bin/darwin/lib/php/extensions/no-debug-non-zts-20190902/opcache.so: mach-o, but wrong architecture
	/Users/ipstenu/Library/Application Support/Local/lightning-services/php-7.4.1+14/bin/darwin/lib/php/extensions/no-debug-non-zts-20190902/opcache.so: stat() failed with errno=22
Failed loading /Users/ipstenu/Library/Application Support/Local/lightning-services/php-7.4.1+14/bin/darwin/lib/php/extensions/no-debug-non-zts-20190902/xdebug.so:  dlopen(/Users/ipstenu/Library/Application Support/Local/lightning-services/php-7.4.1+14/bin/darwin/lib/php/extensions/no-debug-non-zts-20190902/xdebug.so, 9): no suitable image found.  Did find:
	/Users/ipstenu/Library/Application Support/Local/lightning-services/php-7.4.1+14/bin/darwin/lib/php/extensions/no-debug-non-zts-20190902/xdebug.so: mach-o, but wrong architecture
	/Users/ipstenu/Library/Application Support/Local/lightning-services/php-7.4.1+14/bin/darwin/lib/php/extensions/no-debug-non-zts-20190902/xdebug.so: stat() failed with errno=22

Warning: PHP Startup: Unable to load dynamic library '/Users/ipstenu/Library/Application Support/Local/lightning-services/php-7.4.1+14/bin/darwin/lib/php/extensions/no-debug-non-zts-20190902/imagick.so' (tried: /Users/ipstenu/Library/Application Support/Local/lightning-services/php-7.4.1+14/bin/darwin/lib/php/extensions/no-debug-non-zts-20190902/imagick.so (dlopen(/Users/ipstenu/Library/Application Support/Local/lightning-services/php-7.4.1+14/bin/darwin/lib/php/extensions/no-debug-non-zts-20190902/imagick.so, 9): no suitable image found.  Did find:
	/Users/ipstenu/Library/Application Support/Local/lightning-services/php-7.4.1+14/bin/darwin/lib/php/extensions/no-debug-non-zts-20190902/imagick.so: mach-o, but wrong architecture
	/Users/ipstenu/Library/Application Support/Local/lightning-services/php-7.4.1+14/bin/darwin/lib/php/extensions/no-debug-non-zts-20190902/imagick.so: stat() failed with errno=22), /opt/homebrew/Cellar/php/8.0.0_1/lib/php/20200930//Users/ipstenu/Library/Application Support/Local/lightning-services/php-7.4.1+14/bin/darwin/lib/php/extensions/no-debug-non-zts-20190902/imagick.so.so (dlopen(/opt/homebrew/Cellar/php/8.0.0_1/lib/php/20200930//Users/ipstenu/Library/Application Support/Local/lightning-services/php-7.4.1+14/bin/darwin/lib/php/extensions/no-debug-non-zts-20190902/imagick.so.so, 9): image not found)) in Unknown on line 0

This is causing wp-cli to be useless and totally non-functional, though. Can’t even run a search/replace :frowning:

I’m not sure if this is related but I get that once I change the PHP version in local without updating the shell.

Also “which wp” is returning

/usr/local/bin/wp

which is my custom installed wp while it should be

/Applications/Local.app/Contents/Resources/extraResources/bin/wp-cli/posix

Hi all,

If you switch to PHP 7.3.5 (bundled with Local), does it resolve the issue?

Additional context: we don’t currently codesign downloadable services in Local (bundled services are signed) as Apple was previously OK with a codesigned application downloading additional binaries. It’s looking like we’re going to need to update our build process to start signing all downloadable Lightning services.

1 Like

How would one point WP CLI to Local’s version of PHP?

FWIW, seems like WP CLI actually uses MacOS’ default PHP. I’m sure at various times I’ve installed other versions via Brew though.

Interesting! That’s odd how it’s respecting PHPRC and not the PATH changes.

Do you have anything in your ~/.bashrc or ~/.zshrc that could be changing PATH?

For what it’s worth, I just tested this on my personal MBP running macOS 11.1 and a Parallels VM running macOS 11 and was unable to reproduce this even when using PHP 7.4.1. So, I think this disproves my theory of Apple tightening up codesigning restrictions like I previously thought. :sweat_smile:

Since the system version of PHP is being reported, I wonder if there’s an issue with the PATH and the version of WPCLI that’s being used.

@jb510 – what do you get when you run:

which wp
wp --version

I’m guessing this will return a version of WPCLI that’s manually installed as opposed to the one that’s shipped with Local.

For what it’s worth, @Xaver was having some odd interactions with the Local site due to the shell using a manually installed version of WPCLI as opposed to the one that was shipped with Local.

It’s not the same issue as this topic, but you might take a look at this topic to see if it helps with debugging what’s going on here:

@clay and @ben.turner

I use ZSH and Oh My Zsh on iTerm2. I don’t have a .bashrc.

My .zshrc doesn’t do anything that would affect PHP that I can think of, I’ve attached just in case you want to “see” them. I can’t promise there isn’t some other setting elsewhere that could… but I looked and I haven’t installed alternative versions of PHP on this machine via brew (yet…). Haven’t had the need yet I guess.
zsh-bash-profile.zip (2.6 KB)

two screenshots, starting up shell from local it runs the script that should set PHPRC, I don’t know why it doesn’t actually do that…

Do you think this could be a ZSH issue? Does that support $PHPRC? Maybe I’ll try swtiching to bash to see if this problem exist there… but ugh I hate bash :wink:

Well… bash does work without that error. Not sure that narrows it down to ZSH or just “my specific config” in ZSH.

Again, left wondering if $PHPRC is valid in ZSH…

I’m also using ZSH and Oh-My-ZSH!

I hate to say it but it works on my machine. I have local versions of php, wp-cli, etc. installed via homebrew or composer as appropriate.

1 Like

I’m having trouble replicating, but I also noticed some odd things when taking a close look at my own .zshrc as well as @jb510’s .zshrc.

Something about this that feels like a $PATH issue, possibly relating to child-shells.

I’d be curious to know what your $PATH looks like. I used this to change the colons to new lines, which I think makes it easier to read. The top lines have a higher precedent than the lower lines:

echo $PATH | tr ':' "\n"

For me, I would have thought that Local’s config would put the Local site items as a higher precedent than anything else, but in actuality, there are a few items that are “put ahead” of those folders:

I think that the reason that there are repeated items in my PATH is due to the Local shell script using exec $SHELL (ie, creating a subshell) as opposed to just sourceing the file.

@jb510 can you try sourceing the “open shell script” instead of running it as a sub-shell? Specifically do:

  1. In Local, click “Open Site Shell”. This will create the shell script.
  2. Edit the file that was run using “open site shell”
  3. Comment out the last line that says exec $SHELL
  4. Save the file
  5. In a non-Local shell, (ie, a new one) try running that script and see how that affects the $PATH

Here’s a screenshot to help visualize:

It’s important to note that when you click the “Open Site Shell” button within Local, the shell script is regenerated, so any edits you make to that script will be wiped out if you try to open the shell from Local.

The reason to try these things is to see if the act of creating a subshell (and therefore, reloading all of the zsh config) is causing issues with how things are being loaded.

Thank you @afragen, confirmation it’s not ZSH/OMZ is a big help. Still don’t know what’s causing it, but gives me hope I can find it in configs.

@ben.turner TY for continuing to try to help with this. I too feel it’s path or permission related. I thought @clay might have been on to something with codesigning being involved.

In this screenshot left side is first run. Default with the path echoed for reference.

I then opened up the shell script in VS Code and commented out the last exec. line.

I then opened a new shell (iterm new window, right side of screenshot). I ran the script, checked which php, :frowning:, checked $PHPRC which appears unset.

I ran through it a second time. New terminal session, Checked exec still commented, ran script, ran ‘export’ and again it’s showing no PHPRC set.

@ben.turner argh, as soon as I hit send on that I realized I didn’t ‘source’ the script I ran it… redoing now.

So… that worked. Notably the path orders are different (as expected??).

Hurray (maybe?). If I comment out source .bash_profile from my .zshrc it works because it’s not prefacing all the paths with things like /usr/bin.

1 Like

@afragen Does your .zshrc source .bash_profile like mine does? Entirely possible I added that years ago and forgot about it.

If it does, does your .bash_profile include sources like mine? Again, entirely possible I add those years ago and forgot about it… and possible maybe they ‘belonged’ somewhere else like .bashrc.

1 Like

Here are my paths.

I do not source my old .bash_profile probably because I didn’t copy over that file when I set this M1 MBA.

1 Like

Nice find! I think you’ve zeroed in on what’s wrong. Taking a look through the .bash_profile file, it seems like most of the PATH related configuration is already in the .zshrc file. You can probably hand move any configuration that you need over to the zshrc file and then remove the source ~/.bash_profile line.

1 Like