Httpd libphp5.so ldap error

Question

Solved by Julz

Thank you!

 $ brew uninstall php56 $ brew install php56 --without-ldap 

So, I'm in need of some help, I've looked around, but I can't find anything to fix the problem.

I've installed Apache and PHP via Homebrew, but for some reason they don't seem to work together.

Apache is installed with httpd24 --enable-rewrite --enable-ssl --with-privileged-ports --with-http2 via the Homebrew/apache tap

PHP is installed with php56 --with-homebrew-apxs --with-apache --with-homebrew-curl --with-homebrew-openssl via the Homebrew/homebrew-php tap

And they all installed correctly, I load the libphp5.so in httpd.conf; Like you do, and when i run sudo httpd -k start / restart I get this:

httpd:
Syntax error on line 173 of /usr/local/etc/apache2/2.4/httpd.conf:
Cannot load /usr/local/Cellar/php56/5.6.20/libexec/apache2/libphp5.so into server: 
dlopen(/usr/local/Cellar/php56/5.6.20/libexec/apache2/libphp5.so, 10): 
Symbol not found: _ldap_control_find
Referenced from: /usr/local/Cellar/php56/5.6.20/libexec/apache2/libphp5.so
Expected in: /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP
in /usr/local/Cellar/php56/5.6.20/libexec/apache2/libphp5.so

I can't for the life of me figure out what's wrong, any help? Apache works fine without the php lib.

Answer 1

I upgraded php56 today via homebrew and had same pb. It seems to be related to ldap support.

Until a fix is provided I suggest uninstalling php56 then reinstalling without ldap

$ brew uninstall php56
$ brew install php56 --without-ldap

Easy and quick.

Answer 2

For anyone else facing this problem, who is unable to disable LDAP support because it is needed for a project they are working on, an alternative method is to cause Homebrew to reinstall PHP by building it from its source code, which I describe below as well as some tips I have found useful over the years for generally debugging issues related to PHP and loading PHP into a web server environment (in this case Apache). I hope the information below is useful to others and saves someone else the time it took to figure this out.

---

For many Homebrew packages when you simply perform a brew install <package> command, Homebrew will install a 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 codebases can take hours to compile!), and in most cases the pre-compiled version is what you want.

However when the pre-compiled version appears to contain bugs or may conflict with other installed software, installing a package from source (or rather having Homebrew reinstall the package from source on your behalf) may be able to solve the issue you are experiencing. It should be noted however that the suggestion solution here may not work for everyone or for all similar issues – the outcome depends on many variables such as where the bug actually exists – for example if the bug is in the source code for the software you are installing, then this solution is unlikely to help, but if the bug is caused by the way the software has been configured or prepackaged with other code it may be of use, and thankfully was in this case.

Fixing the Issue: Reinstalling PHP from Source via 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

Notice the special Homebrew --build-from-source flag – this tells Homebrew not to install a pre-built version of the package you are installing, but to re-build the package from its source code repository.

You may actually find as I did, that I first had to remove PHP 5.6 (via brew uninstall php56 ), before running the above command (you could actually change the reinstall subcommand to just install after performing an uninstall to be semantically correct, but the reinstall command works regardless of whether the package is already installed or not).

Reinstalling PHP Extension Modules after Reinstalling PHP

I also found it necessary to reinstall the additional PHP module packages I had installed (such as OPCache), by running the relevant brew reinstall php56-<module> after PHP 5.6 had been reinstalled by building from source code.

You can see which other PHP module packages you have installed via Homebrew by running brew list | grep php brew list | grep php . It should be safe to simply reinstall them all, which you could do easily by running the following:

brew list | grep php56 | xargs -I{} brew reinstall {}

If you want to be more targeted in what you reinstall, you should be able to see which PHP modules are failing to load (if there are any conflicts) by reviewing the output of starting your web server, reviewing your web server logs, or reviewing the output of simply calling the PHP binary on the command line (assuming your path is setup correctly to point to the version of PHP you just installed with Homebrew, which it usually would be).

Some notes on these places to look for debugging information can be found below:

Apache HTTPD Startup Debug Output

To see verbose output from starting up 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 wrapper script around the httpd binary - the -k restart option tells httpd which function to perform (in this case to restart – you can see all the supported options by running man httpd ), and the -e flag allows you to set the verbosity level - the default being effectively silent. Setting -e to the debug level provides the highest level of output so if there is an issue loading one of the configured Apache modules you would see it in the output of running the above command. As such this is often a good place to start if you find your Apache instance is not working as expected.

Apache HTTPD Error Logs on OS X

To review the Apache logs on OS X, open the Console.app (which can be found in the /Applications/Utilities/ folder) and expand the /var/log/apache2/ folder in the Log List side bar, and then select the error_log file. Here you should see additional output from Apache as it loads (its good to have Console.app open while you run the sudo httpd -k restart -e debug command from the console).

If PHP itself is having issues loading any of its modules, you should see these errors relating to this in the error_log in Console.app.

You can also have another Terminal/console window open and run sudo tail -f /var/log/apache2/error_log as an alternative to using Console.app. Using tail -f also updates in an effectively instantaneous fashion, while the output displayed in the Console.app can sometimes lag behind actual events and you may sometimes need to manually refresh if you don't see the output you are expecting.

PHP Startup Errors

Lastly, to see if PHP is experiencing any errors without adding the layer of complexity of a web server's own loading process, you can just run PHP on the command line and see if PHP emits any errors there.

It is worth noting that on most systems the way PHP is configured to run via the command line and how it is configured to run within Apache is generally the same, especially with regards to which extension modules are loaded, but if your system is configured differently you may need to use a combination of checking the error log output from your web server as well as the output from running PHP directly on the command line to ensure that all loading errors/conflicts have been fully resolved.

Running PHP with the -v flag to get PHP to print its current build information is usually a nice quick way to see what is going on, and doesn't leave the PHP binary in REPL mode (waiting for user input):

php -v

If any of the PHP modules (extensions) that you have configured in php.ini or another .ini file that is loaded in via php.ini , are having issues loading, you should see errors output to the console just above the version information that PHP prints. For example you may 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 can see an error related to the loading of the libsodium ( sodium ) PHP extension module, due to a conflict between the build settings. In this example to illustrate a potential conflict, PHP had been previously installed using the --with-debug flag, whereas the reinstalled version lacked this setting. Another option would have been to reinstall and rebuild PHP from source code with the debug option enabled too ( brew reinstall php56 --build-from-source --with-debug ).

Although the causes of module conflicts can vary, you should usually find that reinstalling any affected PHP extension module packages with Homebrew (once PHP itself has been reinstalled) will resolve the conflicts. In this case, I ran the following command to reinstall the PHP libsodium package:

brew reinstall php56-sodium

Once the installation of the module had completed, when I re-ran php -v , the errors relating to the loading of this module were no longer present, and I was able to confirm that the libsodium extension module had successfully loaded into PHP by checking the output of php -m (which tells PHP to list all of the loaded modules), and then I used grep "sodium" (the full command being php -m | grep "sodium" ) in this case to just display any lines from php -m that contain the string sodium .

You can replace the specific PHP extension module you are having issues with in the commands above, eg swapping sodium for opcache , etc.

PHP Module Extensions Not Installed via Homebrew

Please note that if you have installed additional PHP extension modules outside of using Homebrew, such as extensions from the PHP PECL repository, it may also be necessary to reinstall one or more of these additional modules after you reinstall PHP via Homebrew. You should consult the installation notes for those additional modules to determine how best to reinstall them.