Bug #70142 [Ver]: Default extension directory is absolute instead of relative

Edit report at https://bugs.php.net/bug.php?id=70142&edit=1 ID: 70142 User updated by: mgcummings at yahoo dot com Reported by: mgcummings at yahoo dot com Summary: Default extension directory is absolute instead of relative Status: Verified Type: Bug Package: Dynamic loading Operating System: Windows 7 PHP Version: 7.0.0beta2 Block user comment: N Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2015-08-03 13:42:40] 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-07-27 17:23:29] 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-07-26 23:50:38] 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 ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=70142&edit=1