php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login go to bug id or search bugs for
Bug #70142 Default extension directory is absolute instead of relative
Submitted: 2015-07-26 23:50 UTC Modified: 2015-08-04 20:22 UTC
Votes: 3 3.7 ± 0.9 1 of 1 (100.0%) 1 (100.0%) 1 (100.0%)
From: mgcummings at yahoo dot com Assigned:
Status: Not a bug Package: Dynamic loading
PHP Version: 7.0.0beta2 OS: Windows 7
Private report: No CVE-ID: None
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.
Quick Fix: Fix committed (Closed) Fixed in release (Closed) Need backtrace (Feedback) Need Reproduce Script (Feedback) Try newer version (Not a bug) Not developer issue (Not a bug) No feedback (No Feedback) Expected behavior (Not a bug) Not enough info (Feedback) Submitted twice (Not a bug) register_globals (Not a bug) PHP version support discontinued (Wont fix) Daylight Savings (Not a bug) IIS Stability (Not a bug) Install GNU Sed (Not a bug) Floating point limitations (Not a bug) No Zend Extensions (Not a bug) MySQL Configuration Error (Not a bug) (description) Block user comment Open Closed Re-Opened Duplicate Critical Assigned Analyzed Verified Suspended Wont fix No Feedback Feedback Not a bug Spam General Issues Filter related JIT (Just In Time compilation) Opcache Output Control Performance problem PHAR related PHP-GTK related PHP.net Systems Operation problem PHP.net Website problem Reflection related Reproducible crash Scripting Engine problem Session related SPL related Streams related Testing related PDO related PDO Core PDO DBlib PDO Firebird PDO MySQL PDO OCI PDO ODBC PDO PgSQL PDO SQLite Compile Issues Compile Failure Compile Warning Configuration Issues Dynamic loading PHP options/info functions Safe Mode/open_basedir related Windows Installer related Web Server problem Apache related Apache2 related CGI/CLI related FPM related IIS related iPlanet related Other web server PHP built-in web server related PWS related Servlet related Calendar problems Calendar related Date/time related Compression related Bzip2 Related Zip Related Zlib related Directory/Filesystem functions Directory function related Filesystem function related Directory Services problems LDAP related Database Functions Adabas-D related DBM/DBA related DBX related FrontBase related Ingres II related InterBase related mSQL related MSSQL related MySQL related MySQLi related OCI8 related ODBC related Oracle related PostgreSQL related Solid related SQLite related Sybase-ct (ctlib) related Data Exchange functions JSON related WDDX related Extensibility Functions COM related FFI (Foreign Function Interface) Java related ncurses related PCNTL related POSIX functions related Program Execution Readline related Semaphore related Win32API related Graphics related EXIF related GD related GetImageSize related Ming related Languages/Translation Gettext related ICONV related MBstring related Recode related Mail Related IMAP related mail function related Math Functions BC math related GNU MP related Math related Encryption and hash functions hash related mcrypt related mhash related OpenSSL related Network Functions FTP related HTTP related Network related SNMP related Sockets related PDF functions PDF related Programming Data Structures Arrays related Class/Object related Strings related Variables related Regular Expressions PCRE related Regexps related Spelling functions Enchant related Pspell related XML functions DOM XML related SimpleXML related SOAP related Tidy XML Reader XML related XML Writer XMLRPC-EPI related XSLT related URL Functions cURL related URL related Unicode Issues I18N and L10N related Unicode Engine related Unknown/Other Function phpdbg PECL PDO_INFORMIX BugFeature/Change RequestDocumentation ProblemSecurity mgcummings at yahoo dot com

[2015-07-26 23:50 UTC] mgcummings at yahoo dot com
Description:
------------
Install PHP 7 anywhere without setting extension_dir option in php.ini and using extension=example.dll and php reports it can't find extension in c:/php/example.dll. Per the comments in the included example php.ini files and the default with past versions the built-in default should be a relative path of "./ext/" on Windows which match the actually location in the build. It is also clear that an absolute path is being used for the default as well since the actual path to my install is d:/php7.0/beta2/ meaning it should be looking in d:/php7.0/beta2/ext/ for the DLLs.

Test script:
---------------
echo %PATH%
php.exe --version

Expected result:
----------------
Not report missing extension DLLs.

Actual result:
--------------
D:\php-7.0\beta2;C:\Windows\system32;C:\Windows
PHP Warning:  PHP Startup: Unable to load dynamic library 'C:\php\php_bz2.dll' - The specified module could not be
found.
in Unknown on line 0



## Pull Requests

Add a Pull Request

## History

[2015-07-27 17:23 UTC] cmb@php.net
-Status: Open +Status: Verified
[2015-07-27 17:23 UTC] cmb@php.net
This is not a regression bug. extension_dir has always defaulted
to an absolute path on Windows[1].

It occurs to me that it would make sense to change that, though,
at least for the distributed binaries.

[1] <https://github.com/php/php-src/blob/php-5.6.11/win32/build/config.w32.h.in#L18>

[2015-08-03 13:42 UTC] ab@php.net
IMHO there were no win changing current situation. For one - c:\php in the path recommended through all the documentation, many systems are likely to depend on this already. But not only - the configure/build scripts are bound to it, too ... fe nmake install will push to c:\php. Besides that - relative paths are in general useless, fe Apache will do chdir to its root dir, having a relative path in php.ini would cause other bug tickets.

Same on Linux. The best solution is just to always use an absolute path. Any Linux distribution will do it, Windows users have a bit more effort because there's no good appreach to retain with the UNIX FS hierarchy. So we basically win nothing exchanging one for another. I'd rather set this to no bug.

Thanks.

[2015-08-03 18:41 UTC] mgcummings at yahoo dot com
Don't know what documentation you maybe looking at AB but this is directly from the include php.ini-development and php.ini-production examples:
; Directory in which the loadable extensions (modules) reside.
; http://php.net/extension-dir
; extension_dir = "./"
; On windows:
; extension_dir = "ext"

Now I do agree that if actual relative paths are used they could cause the many problems you stated. What I am saying is since on Windows when PHP is built it puts them in ext/ that the default should reflect that so C:/php/ext/ would be fine along with correctly the examples. IF I'm understanding you right the comment is also wrong for where the default under Linux is as well.

The other option is to change the make files etc so all the extensions are put into the root build directory where PHP is looking for them. IMHO that would be a bad idea but either way IMHO it's important that where the extensions are build and where PHP expects to find them plus where the examples say it will be look all need to be the same. Changing the examples and the one path for where PHP looks is easier I'm sure. This could also be used as an opportunity to bring the Windows and Linux default builds into closer alignment by having both use ext/ if not overridden.

[2015-08-04 16:07 UTC] ab@php.net
-Status: Verified +Status: Not a bug
[2015-08-04 16:07 UTC] ab@php.net
@mgcummings i was referring to the documentation on php.net, so not only regarding INI. c:\php is mentioned in various contexts.

Extensions have to be in a separate dir, otherwise it'll produce startup errors trying to load random DSO. On Linux fe they're put into ./modules when compiled manually. But it is anyway a separate topic - one thing is how it's build, completely another - how it's packaged.

If you compile PHP yourself, no matter where and do (n)make install - the extension dir path will need to be adjusted manually. Now - the packaged version on Linux has paths/configs predefined by a package maintainer. An equivalent on Windows were some installation package that we don't have ATM. Those paths concern various SAPIs which can be used with webservers which we are not in control of. Also, due to the nature of zip distribution it is not possible to provide predefined paths. We'd really need some packaging on Winows, otherwise it is just exchanging one issue with another, which has probably a little sense. Packaging is what the WAMP redistributors do fe.

Thanks.

[2015-08-04 20:22 UTC] mgcummings at yahoo dot com
I'm actually using the builds from http://windows.php.net/ and not building it myself so that's why I'm saying the default build directories etc should match and it is on anyone that repackage it like WAMP redistributors would have to make the adjustments if they put it some where else just like most Linux distros do to have php.ini somewhere in /etc/ and the extensions in /usr/ or /var/.

Guess kind of my point is that if I did compile PHP on Linux, which I have done a few times, if I install it to say /usr/local/bin/ with make afterwards (I believe that's the default location) and I copy over one of the example php.ini in that directory as well and uncommented some of the extension lines PHP will find the ones it's built with in the modules/ directory without me having to set extension_dir. On Windows doing the same steps or downloading the pre-built binary it'll give me an error that it can't find any of the extensions because they are built in ext/ but it's looking in the same directory as PHP itself for them. So the default for Windows is not inline with the other platforms and need to be fixed.

Just to summarize regardless of platform where php by default looks for the extensions should match where they by default are built for that platform and that location should match with the locations from the comments in the example php.ini files that are include plus in any of the other docs where it is talked about. It is then on groups like OpenSuSE, WAMP etc to change it in their builds if they want it somewhere else but what you get from *.php.net should 'Just work' in the case of the binaries and if you compile it yourself as well without overriding anything when put in the default build location.

 Copyright © 2001-2022 The PHP Group All rights reserved. Last updated: Fri Dec 02 03:05:53 2022 UTC