Building php@7.0 from source fails on Mojave
nemphys opened this issue · 5 comments
I was forced to try to build php@7.0 from source due to the icu4c update to v.67.1, but the build fails:
==> ./buildconf --force
==> ./configure --prefix=/usr/local/Cellar/php@7.0/7.0.33 --localstatedir=/usr/local/var --sysconfdir=/usr/local/etc/php/7.0 --with-config-file-path=/usr/local/etc/php/7.0 --with-config-file-scan-dir=/usr/local/etc/php/7.0/conf.d --with-pear=/usr/local/Cellar/php@7.0/7.0.33/share/php@7.0/pear --enable-bcmath --enable-calendar
Last 15 lines from /Users/Nemphys/Library/Logs/Homebrew/php@7.0/02.configure:
checking for WebPGetInfo in -lwebp... yes
checking for jpeg_read_header in -ljpeg... yes
checking for png_write_image in -lpng... yes
If configure fails try --with-xpm-dir=
checking for fabsf... yes
checking for floorf... yes
checking for GNU gettext support... yes
checking for bindtextdomain in -lintl... yes
checking for ngettext in -lintl... yes
checking for dngettext in -lintl... yes
checking for dcngettext in -lintl... yes
checking for bind_textdomain_codeset in -lintl... yes
checking for GNU MP support... yes
checking for __gmpz_rootrem in -lgmp... no
configure: error: GNU MP Library version 4.2 or greater required.
I checked and gmp seems to be installed properly:
gmp: stable 6.2.0 (bottled)
Any ideas?
Can confirm. No ideas.
Any news on this one?
It seems that this is not a Mojave issue after all; after upgrading to Catalina, I am facing the exact same issue while trying to build php@7.0 from source.
I would recommend checking out https://github.com/shivammathur/homebrew-php. I just found out about it but it as of now is actively maintained unlike exolnet's version here.
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.