Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] Allow loading extensions by name »

[RFC] Allow loading extensions by name

php.internals

François Laupretre

10 years ago
Please read and comment : https://wiki.php.net/rfc/load-ext-by-name Regards François --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus

Fleshgrinder

10 years ago
On 5/10/2016 3:22 PM, François Laupretre wrote:
> Please read and comment : > > https://wiki.php.net/rfc/load-ext-by-name >
+1 and I am wondering why nobody else ever came to this idea.
-- Richard "Fleshgrinder" Fussenegger

Stas Malyshev

10 years ago
Hi!
>> Please read and comment : >> >> https://wiki.php.net/rfc/load-ext-by-name
The RFC says " it is currently impossible to write a single configuration file that will work in both environments" - but even with extension fix, wouldn't it be still impossible since Windows are Unix paths would probably be different?
-- Stas Malyshev smalyshev@gmail.com

Fleshgrinder

10 years ago
On 5/10/2016 6:54 PM, Stanislav Malyshev wrote:
> Hi! > >>> Please read and comment : >>> >>> https://wiki.php.net/rfc/load-ext-by-name > > The RFC says " it is currently impossible to write a single > configuration file that will work in both environments" - but even with > extension fix, wouldn't it be still impossible since Windows are Unix > paths would probably be different? >
Usage of slashes and relative paths works perfectly fine in Windows; or do you mean something different?
-- Richard "Fleshgrinder" Fussenegger

Fleshgrinder

10 years ago
On 5/10/2016 6:56 PM, Fleshgrinder wrote:
> On 5/10/2016 6:54 PM, Stanislav Malyshev wrote: >> Hi! >> >>>> Please read and comment : >>>> >>>> https://wiki.php.net/rfc/load-ext-by-name >> >> The RFC says " it is currently impossible to write a single >> configuration file that will work in both environments" - but even with >> extension fix, wouldn't it be still impossible since Windows are Unix >> paths would probably be different? >> > > Usage of slashes and relative paths works perfectly fine in Windows; or > do you mean something different? >
Just checked it with a simple script on Windows 7 with PHP 7.0.6. Slashes are no problem but relative paths seem problematic, hence, there would be the problem regarding `C:/some/path` vs. `/some/path`. This RFC would still be a big step ahead because we could do something like the following: php -v PHP 7.0.6 (cli) (built: Apr 28 2016 13:48:13) ( NTS ) Copyright (c) 1997-2016 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies php -d zend_extension=xdebug -v PHP 7.0.6 (cli) (built: Apr 28 2016 13:48:13) ( NTS ) Copyright (c) 1997-2016 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies with Xdebug v2.4.0, Copyright (c) 2002-2016, by Derick Rethans php composer install php -d zend_extension=xdebug test This is currently not possible.
-- Richard "Fleshgrinder" Fussenegger

François Laupretre

10 years ago
Hi, Le 10/05/2016 à 18:54, Stanislav Malyshev a écrit :
> The RFC says " it is currently impossible to write a single > configuration file that will work in both environments" - but even with > extension fix, wouldn't it be still impossible since Windows are Unix > paths would probably be different?
Yes, of course. As written in the 'Open Issues' section, the fix does not pretend solving every incompatibilities between windows and Unix configurations. I just say, that, in several cases, I had to duplicate configuration files where the only differences were extension file names (mostly when configuration didn't override default paths). Regards François --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus

Rowan Collins

10 years ago
On 10/05/2016 17:54, Stanislav Malyshev wrote:
> Hi! > >>> Please read and comment : >>> >>> https://wiki.php.net/rfc/load-ext-by-name > > The RFC says " it is currently impossible to write a single > configuration file that will work in both environments" - but even with > extension fix, wouldn't it be still impossible since Windows are Unix > paths would probably be different? >
The RFC already disclaims that:
> This RFC does not pretend solving every difference that may exist > between Windows and Unix configurations. Where paths are set, > the differences will remain.
It also explains how this makes it easier for some people, and some tools, and is therefore worth doing. Regards,
-- Rowan Collins [IMSoP]

Lester Caine

10 years ago
On 10/05/16 17:27, Fleshgrinder wrote:
>> Please read and comment : >> > >> > https://wiki.php.net/rfc/load-ext-by-name >> > > +1 and I am wondering why nobody else ever came to this idea.
The idea has been proposed before, but the addition of php_ for windows installs has not been universally applied. Extensions like eAccelerator, adodb and other third party extensions that did not form part of the windows 'installation' files. Most of these have been killed off by the restructuring of the core so it's probably less of a problem now than 5 years ago! Another negative is the fact that most Linux installations do not use entries in the php.ini file to enable extensions, preferring to manage them via the package manager. THAT particular practice is something I already copy back to the windows installs, using individual .ini files for each extension, and stripping those extensions and settings from the main php.ini. This is not simply a matter of adding another load mechanism to the mix, so any rfc should perhaps bear in mind all the aspects of 'package management' process? Certainly it's not quite as simple as assuming windows extensions start php_ and end .dll ...
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Fleshgrinder

10 years ago
On 5/10/2016 9:01 PM, Lester Caine wrote:
> The idea has been proposed before, but the addition of php_ for windows > installs has not been universally applied. Extensions like eAccelerator, > adodb and other third party extensions that did not form part of the > windows 'installation' files. Most of these have been killed off by the > restructuring of the core so it's probably less of a problem now than 5 > years ago! > > Another negative is the fact that most Linux installations do not use > entries in the php.ini file to enable extensions, preferring to manage > them via the package manager. THAT particular practice is something I > already copy back to the windows installs, using individual .ini files > for each extension, and stripping those extensions and settings from the > main php.ini. > > This is not simply a matter of adding another load mechanism to the mix, > so any rfc should perhaps bear in mind all the aspects of 'package > management' process? Certainly it's not quite as simple as assuming > windows extensions start php_ and end .dll ... >
Handling of the prefix is a no brainer. Just check for php_NAME.dll and fallback to NAME.dll on Windows otherwise. If both fail error out. The approach to split ini files does not work on CLI. UNIX: `php -d extension=foo.so -d zend_extension=bar.so` WIN: `php -d extension=php_foo.dll -d zend_extension=php_bar.dll` RFC: `php -d extension=foo -d zend_extension=bar` Are there really extension on Windows without `.dll` extension? I highly doubt it and would consider erroring out to be okay. Users can still specify the exact path if the want to. function load_extension($name) { $extension_dir = ini_get('extension_dir'); $extension_dir = rtrim($extension_dir, DIRECTORY_SEPARATOR); $extension_dir .= DIRECTORY_SEPARATOR; if (DIRECTORY_SEPARATOR === '\\') { foreach (['php_', ''] as $prefix) { $path = $extension_dir . $prefix . $name . '.dll'; if (is_file($path)) { return do_load_extension($path); } } else { $path = $extension_dir . $name . '.so'; if (is_file($path)) { return do_load_extension($path); } } return do_load_extension($name); } Something along these lines should do it (of course in C). :)
-- Richard "Fleshgrinder" Fussenegger

Lester Caine

10 years ago
On 10/05/16 20:18, Fleshgrinder wrote:
> WIN: `php -d extension=php_foo.dll -d zend_extension=php_bar.dll`
I would be most surprised to find windows users running php command line, but I suppose I am somewhat out of the loop on that side. All my windows users run PHP on a web server and have trouble even accessing the command line. I don't think .so extension is still being used on windows installs. THAT was another 'fix' used to make installation of third party extensions easier. Windows did not worry about which extension was used in the past, but nowadays the problem is ensuring the correct build of extension is accessed and while 32bit is still the safer base, it's all too easy to get them mixed up with 64bit builds. All of MY recent windows installs have had to be 32bit so this creates a conflict with PHP7's assumption that modern target will be 64bit ;) TODAY the windows php.ini needs to be managed to ensure that the correct paths are used to the correct build, and personally I'd rather not 'simplify' something which has a much bigger impact - and adding a build identifier to the file name may be a better fix than trying to rely on the path to ensure the correct build is accessed.
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

François Laupretre

10 years ago
Hi, Le 10/05/2016 à 22:07, Lester Caine a écrit :
> Windows did not worry about which extension was used > in the past, but nowadays the problem is ensuring the correct build of > extension is accessed and while 32bit is still the safer base, it's all > too easy to get them mixed up with 64bit builds. All of MY recent > windows installs have had to be 32bit so this creates a conflict with > PHP7's assumption that modern target will be 64bit ;) TODAY the windows > php.ini needs to be managed to ensure that the correct paths are used to > the correct build, and personally I'd rather not 'simplify' something > which has a much bigger impact - and adding a build identifier to the > file name may be a better fix than trying to rely on the path to ensure > the correct build is accessed.
Right. We could include a build ID in file names. And adapt the way we compute file names from extension names. But I don't see how this concern conflicts with the RFC. Regards François --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus

Joe Watkins

10 years ago
Morning,
> In this case, it is currently impossible to write a single configuration
file that will work in both environments, forcing developers to manually maintain two separate versions of the file. I'm aware this has been mentioned in this thread, and I've read the open issue disclaimer. The RFC does not solve the problem it is trying to solve. It's still going to be impossible to have a single configuration file. The only win seems to be when using php from the command line, or in documentation. Since the mechanism for loading extensions has been the same for so long, and since that knowledge is well dispersed among those who require it, I'm not really seeing the point in changing anything. The idea that we could one day have a configuration file for both platforms seems like a pipe dream, so this can't really be considered a "step closer" to that; It's never going to happen. Cheers Joe On Tue, May 10, 2016 at 11:27 PM, François Laupretre <francois@php.net> wrote:

Lester Caine

10 years ago
On 11/05/16 05:59, Joe Watkins wrote:
> The idea that we could one day have a configuration file for both > platforms seems like a pipe dream, so this can't really be considered a > "step closer" to that; It's never going to happen.
That is my thought as well. Getting windows installations of PHP working with the third party clients needed to complete the jigsaw is irritating at least at the moment. It's bad enough trying to tell nieve users how to check just which client library their system is using when windows already hides the extensions from them, and further hiding just which extension PHP is using ... or guessing if the file has php_ in front. Is not helping windows users. Very few Linux based installs use the php.ini file as shipped, so there is little point making changes to that just for the windows installs anyway? I would like to see the name problem solved, but php_ was added for some very good reason at that time, and then ignored by third party extensions, which is now probably irrelevant, but I would suggest that THAT should perhaps be the target in PHP8 along with a standardising of named ini files containing the associated entries rather than yet another 'sticking plaster' on something which is not going to help lon term.
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

François Laupretre

10 years ago
Le 11/05/2016 à 06:59, Joe Watkins a écrit :
> Morning, > >> In this case, it is currently impossible to write a single > configuration file that will work in both environments, forcing > developers to manually maintain two separate versions of the file. > > I'm aware this has been mentioned in this thread, and I've read the open > issue disclaimer. > > The RFC does not solve the problem it is trying to solve. > > It's still going to be impossible to have a single configuration file. > The only win seems to be when using php from the command line, or in > documentation. > > Since the mechanism for loading extensions has been the same for so > long, and since that knowledge is well dispersed among those who require > it, I'm not really seeing the point in changing anything. > > The idea that we could one day have a configuration file for both > platforms seems like a pipe dream, so this can't really be considered a > "step closer" to that; It's never going to happen.
I realize that I shouldn't have mentioned the possibility to unify Windows/Unix configurations, even if I personally have cases where WIndows & Unix INI files need to be duplicated just because of 'extension=' lines. Once again, we are stuck in 'if it doesn't solve everything, it's useless'. So, please consider it just make things easier for documentation writers and end-users. You may think that 'the knowledge is well dispersed' but, about every months, I see people from project teams coming at me and asking why the 'extension=php_xxx.dll' line they found on Internet doesn't work on their Linux installation. After years of similar requests, I'm proposing this change. But I'm probably wrong and it is clear that everyone in the world has the same knowledge about PHP as yours or mine! Regards François

Fleshgrinder

10 years ago
On 5/10/2016 10:07 PM, Lester Caine wrote:
> I would be most surprised to find windows users running php command > line, but I suppose I am somewhat out of the loop on that side. All my > windows users run PHP on a web server and have trouble even accessing > the command line. >
I am using Windows and the CLI all day professionally. Yes, people tend to think like that but it is ancient thinking. Windows is a very capable operating system and allows you to perform all tasks. Although I have to admit that PHP tends to be very slow on Windows compared to Linux, that is a fact.
-- Richard "Fleshgrinder" Fussenegger

Pierre Joye

10 years ago
On Thu, May 12, 2016 at 2:34 AM, Fleshgrinder <php@fleshgrinder.com> wrote:
> On 5/10/2016 10:07 PM, Lester Caine wrote: >> I would be most surprised to find windows users running php command >> line, but I suppose I am somewhat out of the loop on that side. All my >> windows users run PHP on a web server and have trouble even accessing >> the command line. >> > > I am using Windows and the CLI all day professionally. Yes, people tend > to think like that but it is ancient thinking. Windows is a very capable > operating system and allows you to perform all tasks. Although I have to > admit that PHP tends to be very slow on Windows compared to Linux, that > is a fact.
Off topic but you are wrong here. As a matter of fact. Check real life benchmarks and raw benchmarks.
-- Pierre @pierrejoye | http://www.libgd.org

François Laupretre

10 years ago
Hi Lester, Le 10/05/2016 à 21:01, Lester Caine a écrit :
> The idea has been proposed before, but the addition of php_ for windows > installs has not been universally applied. Extensions like eAccelerator, > adodb and other third party extensions that did not form part of the > windows 'installation' files. Most of these have been killed off by the > restructuring of the core so it's probably less of a problem now than 5 > years ago!
As Fleshgrinder suggested, we can easily search for 'php_<name>.dll' and, if not found, then '<name>.dll'. This would occur on Windows only.
> Another negative is the fact that most Linux installations do not use > entries in the php.ini file to enable extensions, preferring to manage > them via the package manager. THAT particular practice is something I > already copy back to the windows installs, using individual .ini files > for each extension, and stripping those extensions and settings from the > main php.ini.
Using extension names instead of file names will also be supported in individual .ini files, just as in the main php.ini. Regards François --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus

Christian Stoller

10 years ago
> -----Ursprüngliche Nachricht----- > Von: François Laupretre [mailto:francois@php.net], Gesendet: Dienstag, 10. Mai 2016 15:23 > > Please read and comment : > > https://wiki.php.net/rfc/load-ext-by-name > > Regards > > François >
Why not just naming them *.so on all platforms and removing the "php_" prefix on Windows? Apache modules on Windows also have the .so suffix. Best regards Christian

Lester Caine

10 years ago
On 11/05/16 07:20, Christian Stoller wrote:
> Apache modules on Windows also have the .so suffix.
THAT was what I was forgetting ;)
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

François Laupretre

10 years ago
Le 11/05/2016 à 08:20, Christian Stoller a écrit :
>> -----Ursprüngliche Nachricht----- >> Von: François Laupretre [mailto:francois@php.net], Gesendet: Dienstag, 10. Mai 2016 15:23 >> >> Please read and comment : >> >> https://wiki.php.net/rfc/load-ext-by-name >> >> Regards >> >> François >> > > Why not just naming them *.so on all platforms and removing the "php_" prefix on Windows? > > Apache modules on Windows also have the .so suffix. > > Best regards > Christian >
AFAIK, the 'php_' prefix is required on WIndows because, without it, some extension file names would conflict with system DLLs. The only way to unify names would be to add the php_ prefix everywhere. This is the mechanism used by Apache, with the 'mod_' prefix. Unfortunately, PHP started on Unix, where the prefix was not needed, and didn't want to change the Unix behavior when Windows support was added. About the '.so' suffix, some systems don't use this as shared lib suffix. HP-UX, for instance, uses '.sl', and others exist, like '.dynlib'. On some systems, you cannot load a dynamic library if its suffix is not the right one. So , '.so' is not usable everywhere. Regards François

Lester Caine

10 years ago
On 11/05/16 12:53, François Laupretre wrote:
> Le 11/05/2016 à 08:20, Christian Stoller a écrit : >>> -----Ursprüngliche Nachricht----- >>> Von: François Laupretre [mailto:francois@php.net], Gesendet: >>> Dienstag, 10. Mai 2016 15:23 >>> >>> Please read and comment : >>> >>> https://wiki.php.net/rfc/load-ext-by-name >> Why not just naming them *.so on all platforms and removing the "php_" >> prefix on Windows? >> >> Apache modules on Windows also have the .so suffix. > > AFAIK, the 'php_' prefix is required on WIndows because, without it, > some extension file names would conflict with system DLLs. The only way > to unify names would be to add the php_ prefix everywhere. This is the > mechanism used by Apache, with the 'mod_' prefix. Unfortunately, PHP > started on Unix, where the prefix was not needed, and didn't want to > change the Unix behavior when Windows support was added. > > About the '.so' suffix, some systems don't use this as shared lib > suffix. HP-UX, for instance, uses '.sl', and others exist, like > '.dynlib'. On some systems, you cannot load a dynamic library if its > suffix is not the right one. So , '.so' is not usable everywhere.
One tends to forget the reason some decisions were made, and when prompted the reasons come back. It's the simple fact that windows will look in the path to see if it finds a copy of a 'library' which is the main problem here, and in my case it's finding copies of the gds32.dll which are the wrong format for the php_interbase.dll extension. I'm seeing the same problem with other third party clients, so in my book it is important to keep using the extension so one knows exactly which files are involved. But as I said I properly planned revamp of handling extensions does make sense?
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Rowan Collins

10 years ago
On 11/05/2016 07:20, Christian Stoller wrote:
> Why not just naming them *.so on all platforms
While it can't be relied on, a file suffix does communicate something about the type of the file. Someone might list the downloads for an extension as "foo.so (for Linux/Unix); foo.dll (for Windows)" and it would be obvious what format the files were in.