Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:37605 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 15440 invoked from network); 12 May 2008 13:26:43 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 May 2008 13:26:43 -0000 Authentication-Results: pb1.pair.com smtp.mail=hsantos@isdg.net; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=hsantos@isdg.net; sender-id=pass Received-SPF: pass (pb1.pair.com: domain isdg.net designates 208.247.131.9 as permitted sender) X-PHP-List-Original-Sender: hsantos@isdg.net X-Host-Fingerprint: 208.247.131.9 ntbbs.winserver.com Windows NT 4.0 (older) Received: from [208.247.131.9] ([208.247.131.9:3701] helo=winserver.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 58/C1-04596-19548284 for ; Mon, 12 May 2008 09:26:43 -0400 Received: from mail.winserver.com ([208.247.131.9]) by winserver.com (Wildcat! SMTP Router v6.3.452.5) for internals@lists.php.net; Mon, 12 May 2008 09:25:25 -0400 Received: from mail.winserver.com ([208.247.131.9]) by winserver.com (Wildcat! SMTP v6.3.452.5) with ESMTP id 1040070359; Mon, 12 May 2008 09:25:23 -0400 Message-ID: <48284556.8000004@isdg.net> Date: Mon, 12 May 2008 09:25:42 -0400 Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 CC: internals@lists.php.net References: <4824219D.3070806@isdg.net> <4824EEAA.3080901@isdg.net> <1210423265.30073.8.camel@localhost> <4825DEB7.2070909@isdg.net> In-Reply-To: <4825DEB7.2070909@isdg.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: internals@lists.php.net Subject: Work Status: Extension_Dir multi-directory DLL loading From: hsantos@isdg.net (Hector Santos) Folks, Well, I got this extension_dir logic work completed based on my PHP 5.2.5 CVS copy of PHP. The feature allows your to set the extension_dir for multiple paths. This is what I had so far in PHP.INI-DIST/RECOMMENDED. ;--------------------------------------------------------------------- ; Directory locations (paths) in which the loadable extensions (modules) ; reside. To add multiple paths, separate paths using ":" (UNIX) for ; ";" (Windows) character. Examples: ; ; UNIX: extension_dir = "/path1:/path2" ; Windows: extension_dir = "\path1;\path2" ; ; Note: Explicit FQFN (Fully Qualified File Name) extension loading ; : Extensions with explicit FQFN can be used to skip the ; extension search in the extension_dir path(s). ; i.e. extension = c:\serverapp\bin\php_wildcat.dll ; ;--------------------------------------------------------------------- extension_dir = "./ext" The source code change was done on the ext\standard\dl.c file. I was about to create the patches for the current PHP52, PHP53 and PHP6 snapshots when I noticed there was a change in PHP53 that was done that allows for explicit FQFN extension= loading. I don't know if this was a result of someone lurking the list and decided to go ahead and do this after reading the related recent thread for the multi-path extension_dir proposal, which is fine, but if they did go about this after seeing the thread, a simple courtesy to post a note of their intention would of been appreciated. Things like this waste people's time. In any case, to see if there was any other stuff related to this, I checked the bug database and found two related past feature request related to this: Bug # 22587 (Mar 2003) extension_path feature Bug # 41310 (May 2007) make extension_dir optional and use absolute paths in "extension = ..." #22587 is pretty much what I am satisfying. #41310 was interesting so I wanted to see if this was possible now. Using my 5.2.5 release installation (which would be the same logic as 5.2.6), I tested the following PHP.INI option: extension_dir="./ext" extension_dir="../../php_wildcat.dll" and of course, the source code logic show this as well. But the PHP53 FQFN change now breaks this. The PHP53 change allow for extension= module loading if the filename has a directory separator, but not supported for temporary loading via a PHP script DL() function. extension=c:\path\php_extension.dll <== works under PHP53 only dl("c:\path\php_extension.dll") <== never supported. I personally think PHP53 change is more correct, but that depends on your point of view. Should the filename loading be off the ROOT path for the PROCESS or off the extension_dir path was what the 5.2 logic. It also depends on what the file name is: FQFN means a complete path (not relative) There could be a change where if the file name has relative folder reference (../) then it could use the extension_dir as the root as it was supported in PHP52. If its FQFN, then its a explicit load. In all, this is what I think: 1) PHP53 breaks PHP52 logic. Although "more correct", its breaks working code so we need to do something there. 2) Consider using a new extension_path to override extension_dir thereby keeping extension_dir PHP52 intact and only apply the multiple path search to the new extension_path, if defined. 3) Continue with the current patch I am doing with extension_dir and if a extension= has a relative path, apply this only to the FIRST path defined in extension_dir. For example: extension_dir="./ext;c:/wildcat;c:/other" extension=php_zip.dll extension=php_wildcat.dll extension=../php_extension2.dll extension=c:\somewhere\php_extension3.dll php_zip.dll has no folder information, so its found its stock ./ext folder. php_wildcat.dll has no folder information, its not in ./ext so the additional paths are checked and its found in c:/wildcat php_extension2.dll has a relative location, so to continue with PHP52 expectations, it will only use the first path "./ext" as its root. php_extension3.dll has a FQFN so its explicitly loaded with the FQFN. Comment? What path do you think its the best way? Again, although PHP53 change logic seems to be more correct, IMO, that is would be so if PHP was new and there was no working code out there. But as it was done now, it does break the PHP52 logic. -- Hector Santos