[PHP-DEV] CVS Account Request: uuuuumesh
To Test -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP in 2003 (leading to PHP 5)
[...] different distribution packages can be built when php releases occure, such as 'php core' which would contain the 'most important' stable extensions, 'php stable' which would contain all stable extensions, and 'php bleeding' which could be a package with the latest development snapshot at time of release. With this also extensions now can take on a life of their own, releasing at different times than php, and visaverse. I think this would make releasing new versions of php much more manageable. From my past experiance, Ive found this sort of idea to be great - if the modules are retrieved else where, otherwise you end up with a support nightmare. Currently in the bug tracker we only need to ask what version of PHP they have and we automatically know what version all the of the modules are as they come bundled. If all the modules are updateable independantly of the PHP release having PHP x.x.x installed is no longer enough release information, we (via the end user) would also have to gather the version number for each module - ouch. Not to mention the painful testing! [eg:] I have 4 installations running 4 different versions of PHP for regression testing and bug fixing. If I relied on 3 different modules and wanted to check 2 versions of each, I would need 4 * 3 * 2 (24) installations - just to test. Im not against the concept of modules, but Id encourage the idea to be well thought out (especially the impact) as well as encouraging them to be thought more of plug-ins which are independant and may well be upgraded. /concerned -- Dan Hardiker [[EMAIL PROTECTED]] ADAM Software Systems Engineer First Creative -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP in 2003 (leading to PHP 5)
I tend to agree that completely separating PHP from the modules does cause a problem when it comes to support modules, etc. However, IMHO I feel that as the numbers of modules written for PHP increases there becomes a greater and greater need to separate modules from the core of PHP. When it comes to bug reporting/fixing, perhaps it's feasible to completely separate bug reporting for each module from PHP itself? For example, if each module is maintained completely separately from PHP with it's own version # then there should also be a separate bug reporting system for bugs found with that module. Also, on that note, is there any hard and fast standard in place for modules/extensions and the minnimum PHP version those modules support? I.e. is there anything that is designed to prevent me from trying to load a module in PHP 4.0 when it won't work with any version of PHP less than 4.2? I mean more than it throwing an error at compile-time of course. When I look at PECL, I envision a system where modules are completely separated from the PHP core. Each module and their maintainer(s) (whomever they are) deal with their own bugs for that module, modules have minnimum PHP core versions for which they work with, etc. We could make this easier by providing a source-forge type of cookie-cutter bug tracking system for each module, and perhaps by making the modules themselves clearly independent of PHP. I'd like to see a system for modules where what modules PHP uses is not defined at compile-time at all by a ./configure statement. Rather, what modules are being used are defined in some sort of configuration file (where the configuration parameters for those modules are also located) and the modules are loaded dynamically. I should be able to go download the GD module and stick it in a subdirectory of /usr/local/lib/php and then edit my modules.conf (or something) file: module name=gd Allow_jpeg=true Allow_tiff=false /module These are all just thoughts I have.. Feedback is more than welcome. I think a system such as this would accomplish a number of (in my mind) benfitial things: 1) Faster and easier installations of PHP By removing all of those compile-time ./configure options it will make PHP much easier to compile and install. Problems with a single module at compile-time won't stop a user from getting PHP running, and if there is a problem when the module is dynamically loaded it will be easier to figure out what's going wrong. 2) More accurate and managable module maintaing If modules are completely separated from PHP itself, then the status of a particular module, the people who are maintaining it, news about the modules, etc. will be easily found. There are more, but it's late and I'm going to get to sleep :) Like I said, feedback is more than welcome and I'd love to work with whomever is interested to move PHP in this direction. Cheers, John -Original Message- From: Dan Hardiker [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 02, 2003 3:59 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] PHP in 2003 (leading to PHP 5) [...] different distribution packages can be built when php releases occure, such as 'php core' which would contain the 'most important' stable extensions, 'php stable' which would contain all stable extensions, and 'php bleeding' which could be a package with the latest development snapshot at time of release. With this also extensions now can take on a life of their own, releasing at different times than php, and visaverse. I think this would make releasing new versions of php much more manageable. From my past experiance, Ive found this sort of idea to be great - if the modules are retrieved else where, otherwise you end up with a support nightmare. Currently in the bug tracker we only need to ask what version of PHP they have and we automatically know what version all the of the modules are as they come bundled. If all the modules are updateable independantly of the PHP release having PHP x.x.x installed is no longer enough release information, we (via the end user) would also have to gather the version number for each module - ouch. Not to mention the painful testing! [eg:] I have 4 installations running 4 different versions of PHP for regression testing and bug fixing. If I relied on 3 different modules and wanted to check 2 versions of each, I would need 4 * 3 * 2 (24) installations - just to test. Im not against the concept of modules, but Id encourage the idea to be well thought out (especially the impact) as well as encouraging them to be thought more of plug-ins which are independant and may well be upgraded. /concerned -- Dan Hardiker [[EMAIL PROTECTED]] ADAM Software Systems Engineer First Creative -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit:
RE: [PHP-DEV] PHP in 2003 (leading to PHP 5)
[John Coggeshall] These are all just thoughts I have.. Feedback is more than welcome. I think a system such as this would accomplish a number of (in my mind) benfitial things: 1) Faster and easier installations of PHP [...] 2) More accurate and managable module maintaing [...] Also, having the php configuration (compile-time) separated from the module configuration (run-time) would enable external build structures (such as the FreeBSD ports system) to install base php installations, and with it tools to update/install/deinstall modules dynamically. For jack-in-the-box (preconfigured) systems/packages like RedHat rpm's / other binary distributions, this would also have the same advantage. [currently 3 or 4 binaries are created depending on the amount of modules you want and in what way you want them configured] -- Dan Hardiker [[EMAIL PROTECTED]] ADAM Software Systems Engineer First Creative -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Status of NSAPI and Servlet SAPIs?
Hello, as a webmaster for largish university using Sun ONE Web Server (former iPlanet) I've been wondering for a while what really is the status of PHP's NSAPI SAPI module? It seems to stay unchanged from release to release, and bugs relating to the worst problem with NSAPI (serving of PHP pages stops at random) seem not to be solved. (And no, it is not a problem with file descriptor limit setting in the operating system.) Fact is, we need a reliably working PHP and currently we don't have that. Which leads me to think about the servlet implementation, which probably would be as efficient on Sun ONE server as NSAPI. Is the servlet SAPI being developed? I tried it as of PHP 4.2.3, and it compiled fine using Sun's JDK 1.4.1_01 on Solaris 8, and with servlet.jar suppied with Sun ONE server. It even partially worked. Now, using PHP 4.3.0 the servlet SAPI doesn't even compile; the makefile directives are badly formed and do not point to correct files. Hasn't anyone tested it before release? I'm willing to test developmnents to both SAPIs and to provide feedback, but I'm not fluent enough in C to contribute code. If one or both of those SAPIs are being phased out, I'd like to hear that too, so that we can make better recommendations to our users. For reference, our platform is - Sun Fire 280R server - Solaris 8 (with recommended patches as of 2002/12) - Sun ONE Enterprise Web Server 6.0SP5 - PHP 4.3.0 -- Jari Lehtonen Unix Network Services University of Turku, Computing Center -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch for #21330 - socket_select()
This is the patch that fix the issue of socket_select that doesn't wait if value for timeval is 0. Tell me what you think. Regards. M.CHAILLAN Nicolas [EMAIL PROTECTED] www.WorldAKT.com Hébergement de sites internets. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for #21330 - socket_select()
On Thu, 2 Jan 2003 [EMAIL PROTECTED] wrote: This is the patch that fix the issue of socket_select that doesn't wait if value for timeval is 0. Tell me what you think. There is no patch Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for #21330 - socket_select()
Well it was attached it looks the mailing list is dening them. It put it online: http://nicos.worldakt.com/socket_select.patch Regards. M.CHAILLAN Nicolas [EMAIL PROTECTED] www.WorldAKT.com Hébergement de sites internets. - Original Message - From: Derick Rethans [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Wez Furlong [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, January 02, 2003 1:21 PM Subject: Re: [PHP-DEV] Patch for #21330 - socket_select() On Thu, 2 Jan 2003 [EMAIL PROTECTED] wrote: This is the patch that fix the issue of socket_select that doesn't wait if value for timeval is 0. Tell me what you think. There is no patch Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for #21330 - socket_select()
hi, Well it was attached it looks the mailing list is dening them. The mailinglist will only let you get through text/plain Attachements. -daniel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for #21330 - socket_select()
Feel free to take a look at the URL then. -- Regards. M.CHAILLAN Nicolas [EMAIL PROTECTED] www.WorldAKT.com Hébergement de sites internets. Daniel Lorch [EMAIL PROTECTED] a écrit dans le message de news: [EMAIL PROTECTED] hi, Well it was attached it looks the mailing list is dening them. The mailinglist will only let you get through text/plain Attachements. -daniel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Patch for #21330 - socket_select()
#21330 actually sounds completely bogus after having looked at the code... --Wez. PS: add diff -u to your .cvsrc On Thu, 2 Jan 2003 [EMAIL PROTECTED] wrote: This is the patch that fix the issue of socket_select that doesn't wait if value for timeval is 0. Tell me what you think. Regards. M.CHAILLAN Nicolas [EMAIL PROTECTED] www.WorldAKT.com Hébergement de sites internets. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for #21330 - socket_select()
[EMAIL PROTECTED] wrote:
Well it was attached it looks the mailing list is dening them.
It put it online: http://nicos.worldakt.com/socket_select.patch
Regards.
M.CHAILLAN Nicolas
[EMAIL PROTECTED]
www.WorldAKT.com Hébergement de sites internets.
I know this doesn't really belong here, but,
I always like to keep my code as small as possible, do I think you
should change:
if (sec != NULL || sec != 0) {
convert_to_long_ex(sec);
tv.tv_sec = Z_LVAL_P(sec);
tv.tv_usec = usec;
tv_p = tv;
}
else {
tv.tv_sec = 0;
tv.tv_usec = 0;
tv_p = tv;
}
to:
if (sec != NULL || sec != 0) {
convert_to_long_ex(sec);
tv.tv_sec = Z_LVAL_P(sec);
tv.tv_usec = usec;
} else {
tv.tv_sec = 0;
tv.tv_usec = 0;
}
tv_p = tv;
But, as I said it's just a fashion statement, and nothing important...
let stand that it will make *any* difference ;)
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ChangeLog
I'll check on this. On Wed, 01 Jan 2003, Wez Furlong wrote: Is there some magic that needs to be done to rotate the ChangeLog? By this I mean: gzip ChangeLog mv ChangeLog.gz ChangeLog2002.gz touch ChangeLog cvs add -kb ChangeLog2002.gz cvs ci -m rotate changelog ChangeLog ChangeLog2002.gz It seems the most recent entry in the log is from the 29th December, and I wonder if some script needs to be kicked to update the log. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -Andrei http://www.gravitonic.com/ What's hard, in hacking as in fiction, is not the writing, it's deciding what to write. -- Neal Stephenson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_3) / acinclude.m4 configure.in /main streams.c
On Wed, 01 Jan 2003, Wez Furlong wrote: wez Wed Jan 1 04:55:38 2003 EDT Modified files: (Branch: PHP_4_3) /php4 acinclude.m4 configure.in /php4/mainstreams.c Log: Workaround a bug in glibc 2.2.9x and later that causes it not to seek to EOF for stdio streams opened with a mode of a+. Wez, How about implementing those persistent STDIO streams for 4.3.1? -Andrei http://www.gravitonic.com/ * Think digital, act analog. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PDF Creation] Insertion of image on a PDF using EzPDF library
Hi all, Here is my problem. I got a web application, who must build a PDF using datas from a MySQL table and a logo (JPEG format), and send the PDF generated by mail. I manage to build the PDF. Instead of sending it via mail, I tried to open it directly on my browser, IE 6.0. All is ok, I see my datas, and the logo. But when I send it via mail, all I got when I open it on Acrobat Reader is datas, but the logo isn't displayed. Instead , I got a grey bow, and an alert message telling me : Image too big. Of course I tried to put an image 15px*15px, so, not that big ;) but it's the same. I really don't understand, and as the library I use is specifical, it's not really easy to find help or documentation. And to be honnest, my application is soon finished, and if I had to change of library, it would take me lot of time :( I would really appreciate any help :) Thanks a lot. Natacha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP in 2003 (leading to PHP 5)
On Thursday, January 2, 2003, at 05:08 AM, John Coggeshall wrote: When it comes to bug reporting/fixing, perhaps it's feasible to completely separate bug reporting for each module from PHP itself? For example, if each module is maintained completely separately from PHP with it's own version # then there should also be a separate bug reporting system for bugs found with that module. I tend not to see this as the real issue. The bug system can be adapted to our needs as we see fit. The bigger issue is the QA team time, energy, and effort that can be expended to all these test scenarios. This type of decision though will have to be made by the PHP/QA team, and not really by PHP-DEV. If this is of concern to you (developers), I suggest you (developers) become active in the QA process. I really don't see this being an issue any different for PHP Developers than currently setup. Which is support only exists for the latest PHP engine (hence the please try newer version bug responses popularity). When I look at PECL, I envision a system where modules are completely separated from the PHP core. Each module and their maintainer(s) (whomever they are) deal with their own bugs for that module, modules have minnimum PHP core versions for which they work with, etc. We could make this easier by providing a source-forge type of cookie-cutter bug tracking system for each module, and perhaps by making the modules themselves clearly independent of PHP. I'd like to see a system for modules where what modules PHP uses is not defined at compile-time at all by a ./configure statement. Rather, what modules are being used are defined in some sort of configuration file (where the configuration parameters for those modules are also located) and the modules are loaded dynamically. I should be able to go download the GD module and stick it in a subdirectory of /usr/local/lib/php and then edit my modules.conf (or something) file: module name=gd Allow_jpeg=true Allow_tiff=false /module Just remember the idea right now is to move things into PECL to get ready for an eventual version freedom from PHP, but that is not happening just yet. Stig Bakken has suggested this in the past, and you'll find it in archives, that this would be taking the first step towards, working out a lot of the bugs if found and getting the process to iron out. Please realize this change also removes the PHP idea of anyone can fix/add/modify to an extension mantra, and forces it to a realm of per extension release manager/authority. While I like this idea (something I and few others have advocated for awhile), it takes a rather 94 degree turn from how PHP has been developed for the last few years. But it also removes the need to worry about what is enabled by default :) 1) Faster and easier installations of PHP By removing all of those compile-time ./configure options it will make PHP much easier to compile and install. Problems with a single module at compile-time won't stop a user from getting PHP running, and if there is a problem when the module is dynamically loaded it will be easier to figure out what's going wrong. This isn't necessarily the right track to take. Remember that Windows users do not have the need/use of a compiler on their local machines always. As such, a system for distributing a binary is required. This has been hashed out, and Stephen Esser was at one time working on implementing it. Please see the archives for more information about this. --- Dan KalowskyThought I'd visit the club, http://www.deadmime.org/~dankGot as far as the door. [EMAIL PROTECTED] - Don't Get Around Much Anymore, [EMAIL PROTECTED]Ella Fitzgerald -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for #21330 - socket_select()
It's also broken as it will not allow for a null value to give an
infinite wait period.
--Wez.
On Thu, 2 Jan 2003, Tularis wrote:
if (sec != NULL || sec != 0) {
convert_to_long_ex(sec);
tv.tv_sec = Z_LVAL_P(sec);
tv.tv_usec = usec;
} else {
tv.tv_sec = 0;
tv.tv_usec = 0;
}
tv_p = tv;
But, as I said it's just a fashion statement, and nothing important...
let stand that it will make *any* difference ;)
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Another question on PHP building on Linux.
built it as a shared module, i.e. later via the apxs-way. Thomas On Thu, 02 Jan 2003 07:35:17 -0700 [EMAIL PROTECTED] (Ananth Kesari) wrote: Hi, We have another question on building PHP on Linux: When building for Apache, we don't get, on Linux, the core PHP part as a separate binary from the Apache module. This is what the hacked up build scripts produced. Thus, instead of having a single core part which can be used by Apache 1.3 module, Apache 2.x module, command line interface program etc, the whole PHP core is bound statically into each of these! We would like to know whether there is a way to do the way we want it to be done by some configure option OR do we need to modify the input files to the autotools to enable this? Thanks, Ananth. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 4.3.0, RedHat 7.3:Fatal error: Nesting level too deep - recursive dependency? in Unknown on line 0, even with empty file
Hi everyone!
Today i compiled 4.3.0 on my Laptop (Redhat 7.3). Compiling
works fine. Running Scripts works (until now) fine. Except,
that i'm getting the same error, with every file i parse (even
with whole empty ones).
The Error is: Fatal error: Nesting level too deep - recursive
dependency? in Unknown on line 0.
I have no auto_prepend oder _append settings defined inside my
php.ini. The error occurs with the apache SAPI and with the
CLI, too.
Does anyone know about this error or / and know how to fix
that? Or may it be a bug??
Thanks for every help!
Regards,
Toby
--
?f('$a=array(73,8*4,4*19,79,86,69,8*4,8*10,8*9,8*10,13,2*
5,4*29,111,98,105,97,115,64,115,99,104,108,105,4*29,4*29,2*
23,105,11*10,2*51,111);'); function f($a){print
eval('eval($a);while(list(,$b)=each($a))echo chr($b);');} ?
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.3.0, RedHat 7.3:Fatal error: Nesting level too deep- recursive dependency? in Unknown on line 0, even with empty file
Make a backtrace and then we will have a clue about what is happening... --Wez. On Thu, 2 Jan 2003, Tobias Schlitt wrote: Hi everyone! Today i compiled 4.3.0 on my Laptop (Redhat 7.3). Compiling works fine. Running Scripts works (until now) fine. Except, that i'm getting the same error, with every file i parse (even with whole empty ones). The Error is: Fatal error: Nesting level too deep - recursive dependency? in Unknown on line 0. I have no auto_prepend oder _append settings defined inside my php.ini. The error occurs with the apache SAPI and with the CLI, too. Does anyone know about this error or / and know how to fix that? Or may it be a bug?? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] HTTP_RAW_POST_DATA in phpinfo() (request)
Hello everyone, I was wondering if you all would be interested in the following: When always_populate_raw_post_data is set to on in php.ini, one would be able to see the value of HTTP_RAW_POST_DATA in phpinfo() output. I found this would have been a nice little time saver for me while working on writing an XML server which accepts raw XML data from HTTP POST. I am interested in receiving any dialogue that is generated by this post. Feel free to CC: me in your discussion as I am not subscribed to this list. If my request is a bad idea, please share this with me so that I may be more security conscious in any future requests/ideas I may come up with for PHP DEV. I imagine you guys get some bizarre, and/or just plain ridiculous requests. On a side note of personal curiousity, what is the most ridiculous/bizarre feature request ever received by this group? Regards, Kris -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch for #21309 - memory + php_error_docref.
Hello, Even if this bug was assigned to sesser, this is a patch that fix the memory managment and that removes perror and replace it by php_error_docref(). It's also online if the mailing is denying it: http://nicos.worldakt.com/ftp_c.patch. Any comment appreciated, thanks. Note: it will probably need some reviews. Regards. M.CHAILLAN Nicolas [EMAIL PROTECTED] www.WorldAKT.com Hébergement de sites internets. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-DOC] streams reference
On Thu, 2 Jan 2003, Sara Golemon wrote: Is there a function to get this specific information? Would that be useful? Maybe something like get_registered_streams(). That does sound like it'd be useful... Unfortunately there isn't a userland function for that. There *IS* however, a PHPAPI call for it: PHPAPI HashTable *php_stream_get_url_stream_wrappers_hash(); It wouldn't take much to make a userland wrapper for it since it already returns a hash table... stream_get_wrappers(); sounds like an appropriate name right, sounds wonderful :) Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Error Loading mcrypt.dll on Windows XP system
Hi Jean Baptiste Favre wrote: Jim Bierlein [EMAIL PROTECTED] a écrit dans le message de news: [EMAIL PROTECTED] My problem is that I cannot get Apache to properly load the mcrypt module, I keep getting the warning message: Unknown(): Unable to load dynamic library 'c:\php-4.3.0-Win32\extensions\php_mcrypt.dll' - The specific module could not be found. Does anyone know what I am missing or if there is a workaround to this issue. Any help would be appreciated. I am kind of new at this. Hi, You need limcrypt.dll which is not provided by default. Just download it here: http://ftp.proventum.net/pub/php/win32/misc/mcrypt/php-4.3-mcrypt.zip , copy the files: php_mcrypt.dll in your extensions directory and libmcrypt.dll in c:\windows\system32, restart your apache and enjoy ;-)) How about adding libmcrypt.dll to dlls folder of the windows distributions? It's hard to find a matching binary on the web. Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Error Loading mcrypt.dll on Windows XP system
On Thu, 2 Jan 2003, Christoph Grottolo wrote: You need limcrypt.dll which is not provided by default. Just download it here: http://ftp.proventum.net/pub/php/win32/misc/mcrypt/php-4.3-mcrypt.zip , copy the files: php_mcrypt.dll in your extensions directory and libmcrypt.dll in c:\windows\system32, restart your apache and enjoy ;-)) How about adding libmcrypt.dll to dlls folder of the windows distributions? It's hard to find a matching binary on the web. We can not do that due to USA export legislation, but it is in the manual now: http://www.php.net/manual/en/ref.mcrypt.php (Requirements) Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
