php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

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
Votes:1
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 Developer Edit
 [2010-02-14 13:47 UTC] ptschnack at yahoo dot com 
Description:
------------
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.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-02-14 20:20 UTC] pajoye@php.net 
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' 

From:   http://windows.php.net/download/

Download link:  

http://windows.php.net/downloads/releases/php-5.3.1-nts-Win32-VC9-x86.msi

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.

Screenshot:    http://www.ptse.org/gmodul_2.jpg

My machine is WinXP Sp3, x86, IIS 5.1.

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

http://windows.php.net/downloads/qa/test/php-5.3.2RC2-nts-win32-VC9-x86.msi
 [2010-02-15 19:14 UTC] svn@php.net 
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=295097
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] pajoye@php.net 
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 PHP.net 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] pajoye@php.net 
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: Sat Dec 21 13:01:31 2024 UTC