|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #30465 Apache fails to load GD DLL but cli ok...
Submitted: 2004-10-17 21:05 UTC Modified: 2004-10-18 00:25 UTC
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: derek at netsimple dot net Assigned:
Status: Not a bug Package: Dynamic loading
PHP Version: 4.3.9 OS: WinXP Pro
Private report: No CVE-ID: None
 [2004-10-17 21:05 UTC] derek at netsimple dot net
Installation notes:
- OS: WinXP Pro
- PHP: 4.3.9 (and also 4.3.1)
  Installed via zip and windows installer (same result)
- Webserver: Apache 2.0.52

The module (php_gd2.dll) I tried seems to load OK from the command line, but not from within Apache.

I have read all the installation documentation, and also grepped yahoo and google for an answer. Nearly all the solutions mention the editing "extension_dir" in the php.ini file. I believe my config is appropriate to my installation...?

The practice of copying dlls to the %SYSTEM% directory seems to have worked for some, but not for me. Anyway, this is not mentioned *anywhere* in the installation notes, so I don't think it's appropriate.

Other things I have tried:
- comment out the extension_dir directive completely
I get a similar error but refers to C:\php4\... even after copying all the available dlls to that location.

Reproduce code:
Extract from configuration files:

c:\program files\apache\apache2\conf\httpd.conf...
LoadModule php4_module "c:/php/4.3.9/sapi/php4apache2.dll"
PHPIniDir "C:/php/4.3.9"
SetEnv PHPRC C:/php/4.3.9
AddType application/x-httpd-php .php

extension_dir = "C:\PHP\4.3.9\extensions"

Expected result:
GD should be found in the extensions directory (where the dll is located) for:
- Apache2

Actual result:
From the command line:

c:\PHP\4.3.9\php.exe -m
[PHP Modules]
gd   <--------------- here it is!

[Zend Modules]

When starting Apache2:

On starting Apache2, I get the following message:
  Unknown(): Unable to load dynamic library 'c:\PHP\4.3.9\extensions\php_dg2.dll'


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2004-10-17 21:17 UTC]
Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

php_dg2.dll it says, i think you have two different php.ini files and did something wrong in one.
 [2004-10-17 21:30 UTC] derek at netsimple dot net
Hi Derick,

Thanks for the quick response.

I only have one php.ini file in the C:\PHP\4.3.9 directory and one in C:\PHP\4.3.9 - searched whe whole c: drive for them. The installation actually put the php.ini file in %WINDOWS% directory, but I moved it back to the 4.3.9 directory.

According to the apache httpd.conf file it should be looking at the C:\PHP\4.3.9 directory anyway - that's where the config says to look.

If I follow the installation instructions to the letter, and the installation doesn't work (ALL the dynamic dlls have this error), there's a bug. It's that simple, no?
 [2004-10-17 21:48 UTC] derek at netsimple dot net
I've amended this to Dynamic loading, but it could just as easily have been 'Installation' (if there was such a section.

Anyway, trying the cli/php.exe program produce an "point_safe_emalloc" error pointing to the php4ts.dll file. I copied the php/4.3.9/php4ts.dll to %WINDOWS%\system32 and was surprised to find a version already there from March 2004...

Killing Apache2, making the copy and starting Apache2 seemed to fix the problem.

Points to note:
- PHP don't function without this file in the system32 dir.
- The installation left the old version of the file in tact. 

 [2004-10-18 00:25 UTC] derek at netsimple dot net
I am amazed at the PHP developers/bug trackers insistance on treating this, and the numerous similar issues, as bogus. Truely amazed!

The attitude seems to be one of "If you can't get it working, then it's your problem". Well, that is partly true when using open source.

My contention remains: If it doesn't install properly, then there's a bug. In this case, an old version of the dll was not replaced by a newer version. If PHP won't work without the dll, and the old version doesn't get replaced by the installation routine, THAT'S A BUG!

The reason I considered the matter closed (not bogus) is that I'd worked out what the problem is. There is (was) a problem. It's real, not bogus.

In the end, I got it sorted out, but your insistance on treating this as bogus it purile - and doesn't do your cause any good.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Jul 24 02:01:29 2024 UTC