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

go to bug id or search bugs for

Bug #44986 PHP fails loading DLLs for extensions in full install
Submitted: 2008-05-13 21:26 UTC Modified: 2008-08-22 18:26 UTC
From: dicks at jetsoft dot com Assigned: jmertic (profile)
Status: Not a bug Package: Windows Installer
PHP Version: 5.2.6 OS: Win2k3 Server
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.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: dicks at jetsoft dot com
New email:
PHP Version: OS:

 

 [2008-05-13 21:26 UTC] dicks at jetsoft dot com 
Description:
------------
Using php-5.2.6-win32-installer.msi, installing into a path with a space char (either the default, "C:\Program Files\PHP" or, for example, "C:\P PHP") makes PHP fail while starting up, if FULL installation was performed.

Error reports show failures trying to load various dlls, and list their paths correctly, but claim that they are not found. This is NOT a permissions problem, nor a search-path problem.

If PHP is (full - that is all options) installed in "C:\PHP" the failure does NOT occur.

If the default installation ("C:\Program Files\PHP", but not all the extensions) is performed, this problem does not occur.
Likewise, an otherwise default installation, to any other directory that I tried, fails to repro the problem.

So far, incomplete evidence suggests that some extensions, while looking for their MIB modules, fail to handle the embedded space char correctly.

Reproduce code:
---------------
Repro:
1. Install from php-5.2.6-win32-installer.msi.
2. In the "Choose Items to Install" dialog, select the dropdown labelled "PHP", and choose "Entire feature will be installed on local hard drive".
3. Complete installation accepting all defaults.
4. Open a DOS-box, and navigate to the installation directory (C:\Program Files\PHP, if you accepted the defaults)
5. Type "php -i" and hit Enter.

Non-repro instructions:
either omit step 2, above (don't do a full install - do a default instead), or change the installation dir to one without a space in the path.



Expected result:
----------------
various PHP information is displayed on the console.


Actual result:
--------------
about a dozen pop-ups and error reports, claiming that, for instance, "C:\Program Files\PHP\ext\OCI.dll" could not be found.

PHP fails to start up.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-05-13 21:34 UTC] dicks at jetsoft dot com 
Note that, in the first paragraph of the description, where the second example path is broken between two lines, the embedded space may not be obvious. The non-default installation dir that failed for me was:

"C:\P<embedded-space>PHP"

This directory only failed with a full install - the default install succeeded.

Actually, to be clear, ALL the installaions succeeded - what failed was the cmd-line invocation (from within the installation dir, whatever it was at the time) of "php -i" after installation.
 [2008-05-14 07:46 UTC] jani@php.net 
Assigned to the installer maintainer.
 [2008-05-14 12:51 UTC] jmertic@php.net 
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 http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

Doing a full install is a bad idea, unless you want every extension enabled and every SAPI installed and configured. Instead, only enable the extensions you want to use.
 [2008-05-14 14:25 UTC] dicks at jetsoft dot com 
You are saying that your lack of testing of your published installer for your product makes any bugs reported on its operation bogus? That will be a difficult position to convince the community of, I think!

The full install was just the simplest description of the repro scenario. I had been installing just the additions that I wanted. Since I didn't have the time to ferret out which additions were at fault, I reported the scenario that was most complete, so that you wouldn't just fix a few of the additions' operation and not catch all the problems.

I would suggest that you not publish MSI's for scenarios that you don't bother to test. As long as you do publish such, you should be expected to be held accountable for their operation.

It WAS PHP, after all, that failed to start up.

Regards,
DickMS
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Apr 25 16:01:28 2024 UTC