[RFC] Allow loading extensions by name

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

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]

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

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

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

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