PHP Startup: Unable to load dynamic library, Windows, Apache 2.2, php 5.2.11

Question

This is becoming a very frustrating issue. I am trying to do a clean install of apache 2.2 and PHP 5.2.11. Everything seems to be configured correctly but the php modules aren't starting...

PHP Warning:  PHP Startup: Unable to load dynamic library '.;C:/Program Files (x86)/Apache Software Foundation/Apache2.2/php/ext/php_mcrypt.dll' - The specified module could not be found.\r\n in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '.;C:/Program Files (x86)/Apache Software Foundation/Apache2.2/php/ext/php_mysql.dll' - The specified module could not be found.\r\n in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '.;C:/Program Files (x86)/Apache Software Foundation/Apache2.2/php/ext/php_openssl.dll' - The specified module could not be found.\r\n in Unknown on line 0

in the php.ini

include_path = ".;C:\Program Files (x86)\Apache Software Foundation\Apache2.2\php"
extension_dir = ".;C:/Program Files (x86)/Apache Software Foundation/Apache2.2/php/ext/"

All the files are there... The .dll files such as ssleay32.dll, libmcrypt.dll, libmysql.dll, libeay32.dll are all installed at...

C:/Program Files (x86)/Apache Software Foundation/Apache2.2/php/

I also included them in the C:\Windows\System32

and even added C:/Program Files (x86)/Apache Software Foundation/Apache2.2/php/ to the windows path.

I have no idea why this isn't working and it feels like a no win situation. Anyone have any ideas on how to get this all working ok?

Answer 1

Try this:

extension_dir = "C:/Program Files (x86)/Apache Software Foundation/Apache2.2/php/ext/"

without starting with the .;

Answer 2

You just uncomment the extension_dir in php.ini

Answer 3

Just for my future self if no-else. This is with PHP 5.2.13 running in Windows on IIS 8.

I got the following error:

PHP Warning: PHP Startup: Unable to load dynamic library 'C:\Program Files (x86)\PHP\ext\php_openssl.dll' - The specified module could not be found.

From phpinfo() the loaded php.ini file was C:\Program Files (x86)\PHP\php.ini.

The extension directory:

extension_dir ="C:\Program Files (x86)\PHP\ext"

These were the last two lines of the php.ini file:

[PHP_SQLSRV]
extension=php_sqlsrv_52_nts_vc6.dll
[PHP_OPENSSL]
extension=php_openssl.dll

The php_openssl.dll and php_sqlsrv_52_nts_vc6.dll files are in the ext directory. The php_openssl.dll isn't corrupt (it's the same file size as one on another machine that's working).

PHP will find the sqlsrv dll but not the openssl dll. No idea why. No amounts of IIS restarting did anything.

The solution until I know better was to install the openssl.dll extension using the Windows PHP installer. You can re-run the installer and select 'Change' and it allows you to add or remove libraries. I can't see any difference in the file or the php.ini file now, but now the file loads.

I suspect actually that my problem was similar to this comment about OpenSSL installation on Windows:

At this point, when you start Apache it will attempt to load php_openssl.dll, but if your setup is anything like mine you will see an error. I prefer to start Apache manually, and the error appears in a dialog box: "The ordinal 4114 could not be located in the dynamic link library LIBEAY32.dll". (I'm not sure whether you would get this message if you started Apache as a service). The Apache log also contains an error message saying that php_openssl.dll cannot be loaded, though that message doesn't name libeay32.dll. Welcome to DLL Hell.

Libeay32.dll enters the picture because php_openssl.dll depends on it (and also on ssleay32.dll). What I think happens is that Apache first tries to load php_openssl.dll programmatically from the path specified by the extension_dir key. But then, the loading of the so-called dependent DLLs is left to Windows' default mechanism. If Windows finds an incompatible version of a dependent DLL, you get the error.

I noticed errors about ssleay32.dll when trying to run php -i from the command line. I just assumed that it didn't have it in the environment. IIS made no mention of any ssleay32.dll errors in its logs.