'Library not loaded' for PHP@7.1 #24
Comments
For now, this seems linked to what was fixed here earlier for 5.6 and 7.0: the ICU4C-64 is needed for 7.1, whereas 7.2 and up from homebrew seem to be using ICU4C-66. I seem to be able to fix this by running the following after switching to php@7.1:
This fetches the 64 version from raw github. Not sure what happens to node or other linked dependencies though. If you want to go back to the supported version by homebrew (for 7.2+):
|
@ptrkcsk I've been running into the same sort of issues today due to updates with openssl and icu4c. Looking into this reinstall php@7.1 from source seems to fix the issues.
Strongly recommended to make sure you have the current versions of both |
Thanks, @JParkinson1991 !
|
Thanks @JParkinson1991 this fixed it. |
Thanks @JParkinson1991 |
@JParkinson1991 Thanks,it works |
@JParkinson1991 thank you. |
This one solves the problem for me (install icu4c 64.2):
|
I was trying to rebuild from source, as @JParkinson1991 suggested in #24 (comment) but I'm getting the error from #27. Any idea why? |
Hi! Thank you for your interest in this repository. Unfortunately, this repository will now be archived with no further actions. We are sorry for the inconvenience. Why are we closing this repository? This repository was only meant as a temporary measure, not a permanent one. Its only purpose was to ease the transition, considering that formulae from the homebrew-core tap are removed almost the day they became unsupported by the vendor. We needed a few more months to allow us to upgrade the code base of the various projects we have. But it was always with the intention of doing those upgrades, not by relying on a repository to keep old php versions artificially alive. We do not condone the use of deprecated software that could lead to serious security vulnerabilities. Why are we not redirecting to another repository? Redirecting to another repository could be interpreted as an endorsement of said repository. If we were to do such a thing, we would not do it without vetting it first. And we do not wish to put the time and energy required in a vetting process of a third party repository. As the reason why a vetting process would be required, consider this. Before installing a software library on all our developer computers from an untrusted source, we would need to make sure that this software library is free from any malicious code (Trojan, ransomware, etc.), both in the repository itself and in the packaged binaries (the homebrew bottles, if any). Thank you for your understanding. |
The text was updated successfully, but these errors were encountered: