|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #51046 'gmodul_2.dll' should be named 'gmodule-2.dll'
Submitted: 2010-02-14 13:47 UTC Modified: 2010-02-16 11:12 UTC
Avg. Score:2.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (100.0%)
From: ptschnack at yahoo dot com Assigned:
Status: Closed Package: Windows Installer
PHP Version: 5.3.1 OS: win xp sp3
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: ptschnack at yahoo dot com
New email:
PHP Version: OS:


 [2010-02-14 13:47 UTC] ptschnack at yahoo dot com
Is it intensional that 'php-5.3.1-nts-Win32-VC9-x86.msi' installs a 'gmodul_2.dll' instead of 'gmodule-2.dll' which php.exe seems to want? 

When php.exe and php-cgi.exe are run from a command line they complain that 'gmodule-2.dll' can't be found. Which makes sense because 'gmodule-2.dll' can't be found. I got rid of this error by renaming 'gmodul_2.dll' to 'gmodule-2.dll'. 

Reproduce code:
Install 'php-5.3.1-nts-Win32-VC9-x86.msi' and open a command box in the directory holding php.exe. Run php.exe. See php.exe report a missing dll. 

Then weep at the continued frustration of hours lost attempting to install PHP to run as CGI under IIS 5.1. (Okay the weeping is not directly associated with this bug. Tears have dried by this point and I am merely resigned to failure.)

Expected result:
php.exe run from the command line runs w/o error.

Actual result:
php.exe run from the command line runs reporting that 'gmodule-2.dll' cannot be found.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2010-02-14 20:20 UTC]
It is named gmodule-2.dll. Where did you fetch PHP or which version exactly? 
 [2010-02-15 16:38 UTC] ptschnack at yahoo dot com
> which version

As reported: 'php-5.3.1-nts-Win32-VC9-x86.msi' 


Download link:

Screenshot shows 'gmodul_2.dll' is installed instead of 'gmodule-2.dll' and the error dialog put up by php-cgi.exe run from the command line. Installer was run with IIS/FastCGI install selected. The screenshot is taken immediately after running the installer.


My machine is WinXP Sp3, x86, IIS 5.1.

Regards, Paul S...
 [2010-02-15 19:13 UTC]
Can you try using the following msi please? It should fix the issue.

 [2010-02-15 19:14 UTC]
Automatic comment from SVN on behalf of pajoye
Log: - #51046, fix long names for enchant deps
 [2010-02-16 01:58 UTC] ptschnack at yahoo dot com
Well... The original installer gets done with its work in less than a minute.

I killed the test install after ~10.5 minutes and after it had racked up 5 minutes of CPU time for each of two msiexec.exe processes for a total 10 minutes CPU time! Now that's a busy installer.

The progress bar was stuck at one blue segment short of 100%.

FWIW, the machine is dual processor. I can't imagine though that this has anything to do with anything.

Good luck!
 [2010-02-16 09:51 UTC]
That makes no sense. It works just fine here (and with the right file names). I'm not sure why msiexec got mad and I'm pretty sure it is not related to this change (only changed the file name). Did you uninstall the previous php first?
 [2010-02-16 10:59 UTC] ptschnack at yahoo dot com
Previous installation (meaning downloaded from you) was completely uninstalled as far as I can tell (files were gone). However when UNinstalling VS.php 2008 this weekend the uninstall hung around at 99% complete for ~10 minutes until I finally killed the process. So, I wouldn't be surprised if there are pieces of various brands of php stuck in the registry or other settings remaining from unfinished uninstalls and my desparate attempts to get PHP to work. 

(VS.php = PHP dev trying to be integrated into Visual Studio. It will be great if they ever get the debugger to work with more than a single source file.)

At any rate, do you suppose that the two msiexec.exe processes were deadlocked? They had to be spinning in tight loops to use all that CPU.

Paul S...
 [2010-02-16 11:12 UTC]
It is possible yes, it is not designed to be run simultaneously (msiexec).

I will close the bug as I tested the msi on various systems and the file names are now correct.

Feel free to open it again or ping me if you met this issue again.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue May 28 18:01:32 2024 UTC