For anyone who is faced with this problem, who cannot turn off LDAP support because it is necessary for the project they are working on, an alternative method is to force Homebrew to reinstall PHP by creating it from the source code that I describe below, as well as some tips that I have found useful over the years to generally debug PHP-related problems and load PHP into a web server environment (in this case, Apache). I hope the information below is useful to others and saves someone else when needed to understand this.
For many Homebrew packages, when you simply run the brew install <package> command, Homebrew will install the pre-compiled version of the software you are installing (which members of the Homebrew community kindly contribute). In most situations, this is great, as it saves a lot of time (because the code is already compiled, and some complex code bases can take hours to compile!), And in most cases, a pre-compiled version is what you want.
However, if the pre-compiled version contains errors or may conflict with other installed software, installing the package from the source (or, rather, using Homebrew, reinstall the package from the source on your behalf) may solve the problem, it is going through. It should be noted, however, that the proposed solution here may not work for all or for all similar problems - the result depends on many variables, such as where the error actually exists, for example, if the error is in the source code for the software that you installation, this is unlikely to help, but if the error is caused by how the software was configured or pre-packaged with different code, it can be useful, and, fortunately, in this case.
Fixing a problem: reinstalling PHP from source through Homebrew
I was able to successfully install PHP 5.6 from Homebrew on OS X 10.10.5 Yosemite by running the following command:
brew reinstall php56 --build-from-source
Pay attention to the special Homebrew flag --build-from-source - this means that Homebrew does not install the pre-installed version of the package you are installing, but re-creates the package from the source code repository.
In fact, you can find what I did, first I had to uninstall PHP 5.6 (via brew uninstall php56 ) before running the above command (you could actually change the reinstall subcommand only install after uninstall for semantic correctness, but the command reinstall works whether the package is installed or not).
Reinstalling PHP extension modules after reinstalling PHP
I also found it necessary to reinstall additional packages of PHP modules that I installed (for example, OPCache) by running the corresponding brew reinstall php56-<module> after PHP 5.6 was reinstalled by creating from source code.
You can see what other packages of PHP modules you installed through Homebrew by running brew list | grep php brew list | grep php . You just need to reinstall them all, which you can do easily by doing the following:
brew list | grep php56 | xargs -I{} brew reinstall {}
If you want to focus more on what you are reinstalling, you should be able to see which PHP modules are not loading (if there are any conflicts) by looking at the output about starting your web server, looking at the logs of your web server, or viewing the output simply calling the PHP binary on the command line (provided that your path is correctly configured to point to the version of PHP that you just installed using Homebrew, which would normally be).
Some notes in these places for finding debugging information can be found below:
Apache HTTPD Startup Debug Output
To see the detailed output from starting Apache on OS X, you can run the following command:
sudo httpd -k restart -e debug
This is an alternative to running sudo apachectl restart , which is a script wrapper around the binary httpd file - -k restart , tells httpd which function to execute (in this case, to restart - you can see all the supported options by running man httpd ), and the -e flag allows set the level of detail - it is effectively disabled by default. Setting -e to the debug level provides the highest level of output, so if there is a problem loading one of the configured Apache modules, you will see it at the output of the above command. Thus, this is often a good place to start if you find that your Apache instance is not working as expected.
Apache HTTPD Error Logs on OS X
To view Apache logs in OS X, open Console.app (which can be found in the /Applications/Utilities/ ) and expand the /var/log/apache2/ folder on the sidebar of the log, and then select the error_log file. Here you should see additional Apache output as it loads (it is useful to use Console.app when running the sudo httpd -k restart -e debug command from the console).
If PHP itself has problems loading any of its modules, you should see these errors related to this in error_log in Console.app.
You can also open another terminal / console window and run sudo tail -f /var/log/apache2/error_log as an alternative to using Console.app. Using tail -f also updates efficiently instantly, while the output displayed in Console.app can sometimes lag behind real events, and sometimes you may need to update manually if you don't see the expected result.
PHP startup errors
Finally, to see if PHP is experiencing any errors without adding the complexity level of its own web server loading process, you can simply run PHP from the command line and see if PHP is emitting any errors.
It is worth noting that on most systems the way that PHP is configured to run through the command line and how it is configured to work in Apache is generally the same, especially with respect to which extension modules are loaded, but if your system is configured differently, you may need to use a combination of checking the output of the error log from your web server, as well as exiting the PHP launch directly from the command line to ensure that all download errors / conflicts are completely resolved.
Running PHP with the -v flag to get PHP to print the current build information is usually a good quick way to see what happens and does not leave the PHP binary in REPL mode (waiting for user input)
php -v
If any of the PHP modules (extensions) that you configured in php.ini or another .ini file loaded via php.ini have problems loading, you should see the error output to the console above about the version information that PHP prints . For example, you can see something like this:
Warning: PHP Startup: sodium: Unable to initialize module Module compiled with build ID=API20131226,NTS,debug PHP compiled with build ID=API20131226,NTS These options need to match in Unknown on line 0 PHP 5.6.20 (cli) (built: Apr 14 2016 14:23:48) Copyright (c) 1997-2016 The PHP Group Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies with XCache v3.2.0, Copyright (c) 2005-2014, by mOo with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies with Xdebug v2.4.0, Copyright (c) 2002-2016, by Derick Rethans with XCache Cacher v3.2.0, Copyright (c) 2005-2014, by mOo
Above, you may see an error related to loading the PHP libsodium ( sodium ) extension module due to a conflict between build settings. In this example, to illustrate a potential conflict, PHP was previously set using the --with-debug flag, while the reinstalled version did not have this option. Another option would be to reinstall and rebuild PHP from source code with the debug option enabled ( brew reinstall php56 --build-from-source --with-debug ).
Although the causes of module conflicts may vary, you should usually find that reinstalling any affected PHP extension module packages using Homebrew (once PHP has been reinstalled) will resolve the conflicts. In this case, I libsodium following command to reinstall the PHP libsodium package:
brew reinstall php56-sodium
After the module was installed, when I re-run php -v , the errors associated with loading this module were no longer present, and I was able to confirm that the libsodium extension libsodium was successfully loaded in PHP by checking the output of php -m (which tells PHP to list all loaded modules), and then I used grep "sodium" (the full php -m | grep "sodium" ) in this case to display only lines from php -m that contain the string sodium .
You can replace the special PHP extension module that you come across in the above commands, for example. swapping sodium for opcache etc.
PHP module extensions not installed through Homebrew
Please note that if you installed additional PHP extension modules outside of using Homebrew, for example, extensions from the PHP PECL repository, you may also need to reinstall one or more of these additional modules after reinstalling PHP through Homebrew. You should consult the installation instructions for these add-on modules to determine how best to reinstall them.