Error when creating new site with (standard!) PHP 8.1.9
Steps to reproduce
Tried twice to create a new site using freshly downloaded/installed Local 6.5 Beta for Apple Silicon.
Got the same error twice: ENOENT while doing something with PHP 8.1.9 (see screenshot).
Looking into the Local Beta package contents, there’s no php-8.1.9+3/bin/darwin-arm64 directory, so that might possibly be the cause.
Downloading and using PHP 8.0.22 makes site creation easy and fast again.
Environment Info
Apple Silicon M1, 16GB RAM.
Describe your environment.
What Operating System are you using?
Monterey 12.6
What versions of site software (Nginx, Apache, PHP, MySQL) is used?
All Local standard except for PHP version.
I can confirm. PHP 8.1.x is missing from ~/Library/Application Support/Local Beta/lightning-services it does exist in ~/Library/Application Support/Local/lightning-services. Why I can select PHP 8.1.9 from Local Beta is a quandary. I can also create the new site in 8.0.x and then switch to 8.1.x, even though that resource, while present in the package contents does not exist in the Application Support folder.
The php-8.1.9 resource does show in the Local Beta package contents, but not in the Local Beta Application Support folder.
I guess PHP-8-1-9 darwin-arm is missing from Application Support because Local 6.5 tries to copy it from its installer package, but can’t find it there (thus the ENOENT error). The php-8.0.22 package was downloaded and installed manually (at least in my case).
Good morning all! Good find, this was an error in the beta build that was uploaded - we’re packaging up a new build this morning and will upload it, but we’ve confirmed locally this isn’t happening anymore. Coming shortly!
@afragen@philby check out the new build here, which should include that fix! Plus some other bug fixes that got merged while in testing - Local Beta 6.5.1
I even completely removed Local Beta brew uninstall --cask --zap local-beta and reinstalled brew install --cask local-beta and PHP 8.1.9 is listed as available and downloaded but it isn’t. I emptied the lightning-services folder in Application Support/Local Beta and still nothing.
On initial startup Local Beta believes that php-8.1.9-.... is installed and located in the lightning-services folder of Application Support, but it isn’t.
Changing the folder name in the Local Beta package contents above from darwin to darwin-arm64 seems to solve the loading problem. However, this is not an arm64 binary. All you need to do is look in Activity Monitor.
I’m sorry if this wasn’t clear from the screenshot / text: as @afragen writes, it’s a problem of path – Local has lighning-services/php-8.1.9+x/bin /darwin/… but needs or searches for lighning-services/php-8.1.9+x/bin /darwin-arm64/…
Interesting, now I understand. Thanks for the additional info/screenshots. Let me show this to the engineers and we’ll see where the wires got crossed.
For a look into “how the sausage is made”… We use Azure to build and distribute Beta and stable Local. With the new Silicon support, we added a build target for darwin-arm64 which should register correctly as an arm64, grab the correct services and package them up.
Long story short, the Azure agent still thought it was an Intel Mac and packaged the Intel versions instead. We moved some steps around in the build script and the right files should be included now!
A quick look at the package contents shows that only PHP is darwin-arm64.
mailhog, mariadb, mysql, nginx are all darwin, indicating they are not compiled for Apple Silicon. Also I don’t see Apache but when downloaded, it too is darwin, again indicating that it’s not compiled for Apple Silicon.
Very handy to see if there’s crummy old Intel code running – next to the current Apple Silicon native LocalWP I just found out that MS Teams is contaminating my clean system with some Intel AudioDeviceDriver garbage.
@afragen We’ll update that /latest folder this morning! Thanks to you both for helping us take a look.
For this release of Local, the screenshot is expected - the Local app itself and updated versions of PHP are compiled for Apple Silicon. The other services (MySQL, mariadb, nginix, Apache, and Mailhog) were not updated. We have additional tickets for re-compiling those but didn’t want to block the release as the performance improvements with core + PHP changes were significant.
Have you noticed any performance issues with those additional processes being Intel? Or are there other impacts of not having everything running as Silicon?
Interesting, now I understand. Thanks for the additional info/screenshots. Let me show this to the engineers and we’ll see where the wires got crossed.
I just found out that MS Teams is contaminating my clean system with some Intel AudioDeviceDriver garbage.