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>

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.

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.

@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.

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.