Re: [PHP-DEV] PHP 4.1.2 for windows
Gabor Hojtsy wrote: From hour to hour we receive questions at [EMAIL PROTECTED] about the availability of PHP 4.1.2 for Windows. First I tried to give an estimate, but now I don't know what to say. Will there ever be a PHP 4.1.2 for windows, or a 4.1.3??? I could easily provide the binaries, but I'm not able to setup a distribution. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Including bandled expat.h
[EMAIL PROTECTED] wrote: On Mon, 11 Mar 2002, Yasuo Ohgaki wrote: Any reason not to including bandled expat.h explicitly? Any comments for possible fix? The bundled file may differ from the used library, so this is not a good idea. I agree. New build system should be fixed, instead. It seems PHP cannot find bandled header now :( [yohgaki@dev DEV]$ LANG=C make /bin/sh /home/yohgaki/cvs/php/DEV/libtool --mode=compile gcc -DSUPPORT_UTF8 -I/home/yohgaki/cvs/php/DEV/ext/pcre/pcrelib -I/home/yohgaki/cvs/php/DEV/ext/wddx -I/home/yohgaki/cvs/php/DEV/ext/wddx -I/home/yohgaki/cvs/php/DEV/main -I/home/yohgaki/cvs/php/DEV -I/usr/include/apache -I/home/yohgaki/cvs/php/DEV/Zend -I/usr/local/include -I/usr/include/libxml2 -I/usr/include/freetype2/freetype -I/usr/local/pgsql/include -I/usr/include/ucd-snmp -DLINUX=22 -DMOD_SSL=208106 -DUSE_HSREGEX -DEAPI -DUSE_EXPAT -I/home/yohgaki/cvs/php/DEV/TSRM -g -Wall -prefer-pic -c /home/yohgaki/cvs/php/DEV/ext/wddx/wddx.c -o ext/wddx/wddx.lo gcc -DSUPPORT_UTF8 -I/home/yohgaki/cvs/php/DEV/ext/pcre/pcrelib -I/home/yohgaki/cvs/php/DEV/ext/wddx -I/home/yohgaki/cvs/php/DEV/ext/wddx -I/home/yohgaki/cvs/php/DEV/main -I/home/yohgaki/cvs/php/DEV -I/usr/include/apache -I/home/yohgaki/cvs/php/DEV/Zend -I/usr/local/include -I/usr/include/libxml2 -I/usr/include/freetype2/freetype -I/usr/local/pgsql/include -I/usr/include/ucd-snmp -DLINUX=22 -DMOD_SSL=208106 -DUSE_HSREGEX -DEAPI -DUSE_EXPAT -I/home/yohgaki/cvs/php/DEV/TSRM -g -Wall -c /home/yohgaki/cvs/php/DEV/ext/wddx/wddx.c -fPIC -DPIC -o ext/wddx/wddx.lo In file included from /home/yohgaki/cvs/php/DEV/ext/wddx/wddx.c:22: /home/yohgaki/cvs/php/DEV/ext/wddx/php_wddx.h:26:19: expat.h: No such file or directory In file included from /home/yohgaki/cvs/php/DEV/ext/wddx/wddx.c:28: /home/yohgaki/cvs/php/DEV/ext/xml/php_xml.h:38:19: expat.h: No such file or directory make: *** [ext/wddx/wddx.lo] Error 1 [yohgaki@dev DEV]$ -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Including bandled expat.h
[EMAIL PROTECTED] wrote: On Mon, 11 Mar 2002, Yasuo Ohgaki wrote: Any reason not to including bandled expat.h explicitly? Any comments for possible fix? The bundled file may differ from the used library, so this is not a good idea. I agree. There is with-expat-dir option also :) Build system should be fixed, then. PHP cannot find bandled header now. (can find lib) [yohgaki@dev DEV]$ LANG=C make /bin/sh /home/yohgaki/cvs/php/DEV/libtool --mode=compile gcc -DSUPPORT_UTF8 -I/home/yohgaki/cvs/php/DEV/ext/pcre/pcrelib -I/home/yohgaki/cvs/php/DEV/ext/wddx -I/home/yohgaki/cvs/php/DEV/ext/wddx -I/home/yohgaki/cvs/php/DEV/main -I/home/yohgaki/cvs/php/DEV -I/usr/include/apache -I/home/yohgaki/cvs/php/DEV/Zend -I/usr/local/include -I/usr/include/libxml2 -I/usr/include/freetype2/freetype -I/usr/local/pgsql/include -I/usr/include/ucd-snmp -DLINUX=22 -DMOD_SSL=208106 -DUSE_HSREGEX -DEAPI -DUSE_EXPAT -I/home/yohgaki/cvs/php/DEV/TSRM -g -Wall -prefer-pic -c /home/yohgaki/cvs/php/DEV/ext/wddx/wddx.c -o ext/wddx/wddx.lo gcc -DSUPPORT_UTF8 -I/home/yohgaki/cvs/php/DEV/ext/pcre/pcrelib -I/home/yohgaki/cvs/php/DEV/ext/wddx -I/home/yohgaki/cvs/php/DEV/ext/wddx -I/home/yohgaki/cvs/php/DEV/main -I/home/yohgaki/cvs/php/DEV -I/usr/include/apache -I/home/yohgaki/cvs/php/DEV/Zend -I/usr/local/include -I/usr/include/libxml2 -I/usr/include/freetype2/freetype -I/usr/local/pgsql/include -I/usr/include/ucd-snmp -DLINUX=22 -DMOD_SSL=208106 -DUSE_HSREGEX -DEAPI -DUSE_EXPAT -I/home/yohgaki/cvs/php/DEV/TSRM -g -Wall -c /home/yohgaki/cvs/php/DEV/ext/wddx/wddx.c -fPIC -DPIC -o ext/wddx/wddx.lo In file included from /home/yohgaki/cvs/php/DEV/ext/wddx/wddx.c:22: /home/yohgaki/cvs/php/DEV/ext/wddx/php_wddx.h:26:19: expat.h: No such file or directory In file included from /home/yohgaki/cvs/php/DEV/ext/wddx/wddx.c:28: /home/yohgaki/cvs/php/DEV/ext/xml/php_xml.h:38:19: expat.h: No such file or directory make: *** [ext/wddx/wddx.lo] Error 1 [yohgaki@dev DEV]$ -- Yasuo Ohgaki Derick Index: ext/wddx/php_wddx.h === RCS file: /repository/php4/ext/wddx/php_wddx.h,v retrieving revision 1.10 diff -u -r1.10 php_wddx.h --- ext/wddx/php_wddx.h 28 Feb 2002 08:26:56 - 1.10 +++ ext/wddx/php_wddx.h 11 Mar 2002 07:02:18 - @@ -23,7 +23,7 @@ #if HAVE_WDDX -#include expat.h +#include ext/xml/expat/expat.h extern zend_module_entry wddx_module_entry; #define wddx_module_ptr wddx_module_entry Index: ext/xml/php_xml.h === RCS file: /repository/php4/ext/xml/php_xml.h,v retrieving revision 1.19 diff -u -r1.19 php_xml.h --- ext/xml/php_xml.h 11 Dec 2001 15:30:51 - 1.19 +++ ext/xml/php_xml.h 11 Mar 2002 07:02:18 - @@ -35,7 +35,7 @@ #if defined(PHP_XML_INTERNAL) -#include expat.h +#include ext/xml/expat/expat.h #ifdef PHP_WIN32 #define PHP_XML_API __declspec(dllexport) -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Site Resource Manager - www.vl-srm.net --- -- Yasuo Ohgaki [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.1.2 for windows
The reason we wanted to wait for Daniel is that he always builds the Windows binaries, and binaries created on other systems might have quirks or dependencies. If he doesn't show up today, I'll use the old 4.1.2 vanilla binaries he sent me a week ago. It won't be with the new Windows fixes, but it'll be on par with the UNIX 4.1.2. Zeev On Mon, 11 Mar 2002, Sebastian Bergmann wrote: Gabor Hojtsy wrote: From hour to hour we receive questions at [EMAIL PROTECTED] about the availability of PHP 4.1.2 for Windows. First I tried to give an estimate, but now I don't know what to say. Will there ever be a PHP 4.1.2 for windows, or a 4.1.3??? I could easily provide the binaries, but I'm not able to setup a distribution. -- Zeev Suraski [EMAIL PROTECTED] http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/pgsql pgsql.c
[EMAIL PROTECTED] wrote: On Mon, 11 Mar 2002, Yasuo Ohgaki wrote: [EMAIL PROTECTED] wrote: On Mon, 11 Mar 2002, Yasuo Ohgaki wrote: Fix possible build error under Windows. # Recent libpq under windows supports PQcmdTuples, right? Nevermind... but the commit message was a very misleading. You're right. I didn't realize that since I didn't take a look at the diff. Fixed build. Added missing ). might be better. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: CLI: Passing arguments to scripts....
The patch looks ok. Go ahead.
Edin
The following path for cli version is concerned with passing arguments
to scripts. I found out that not all ways work correct and $PHP_SELF is not
set
at all. The four example below explain the patch. All four execute:
echo $PHP_SELF\n;
echo join($argv,',').\n;
1) Execute a file using -f and pass 'a -b c' - before patch scriptfile was
set to a - didn't work
$ php -f /t/temp/arg.php a -b c
/t/temp/arg.php
/t/temp/arg.php,a,-b,c
2) Execute a file using without and pass 'a -b c' - before patch
scriptfile was set to a - didn't work
$ php /t/temp/arg.php a -b c
/t/temp/arg.php
/t/temp/arg.php,/t/temp/arg.php,a,-b,c
3) Execute code directly and pass 'a -b c' - before patch scriptfile was
set to a - didn't work
$ php -r 'echo $PHP_SELF\n.join($argv,,).\n;' a -b c
-
-,a,-b,c
4) Execute stdin and pass 'a -b c' - before patch passing arguments wasn't
possible at all
$ echo '?echo $PHP_SELF\n.join($argv,,).\n;?' | php -- a -b c
-
-,a,-b,c
There was no need to change function ap_php_getopt as it does handle -- to
end interpreting arguments.
But i added PHP_SELF and set it to either the executed script or - for
stdin/run code. The
value for argv[0] seen by script is set to the same value to make argument
enumerating consistent.
An opportunity would be setting argv[0] of script to argv[0] of cli. This
way the user could get the
execution-path on some systems.
Any suggenstions? May i commit the change?
regards
marcus
diff -u -w -r1.9 php_cli.c
--- sapi/cli/php_cli.c 8 Mar 2002 09:55:58 - 1.9
+++ sapi/cli/php_cli.c 10 Mar 2002 14:53:17 -
@@ -240,7 +241,9 @@
prog = php;
}
- php_printf(Usage: %s [-h] [-s] [-v] [-i] [-f file] | {file
[args...]}\n
+ php_printf( Usage: %s [options] [-f] file [args...]\n
+ %s [options] -r code [args...]\n
+ %s [options] [-- args...]\n
-s Display colour syntax
highlighted source.\n
-w Display source with
stripped comments and whitespace.\n
-f file Parse file.\n
@@ -253,8 +256,12 @@
-l Syntax check only
(lint)\n
-m Show compiled in
modules\n
-i PHP information\n
- -r code Run PHP code\n
- -h This help\n, prog);
+ -r code Run PHP code without
using script tags ?..?\n
+ -h This help\n
+ \n
+ args...Arguments passed to
script. Use -- args when first argument \n
+starts with - or script
is read from stdin\n
+ , prog, prog, prog);
}
/* }}} */
@@ -301,6 +308,7 @@
int no_headers=1;
int orig_optind=ap_php_optind;
char *orig_optarg=ap_php_optarg;
+ char *arg_free=NULL, **arg_excp=arg_free;
char *script_file=NULL;
zend_llist global_vars;
int interactive=0;
@@ -512,18 +520,32 @@
}
}
+ /* only set script_file if not set already and not in
direct mode and not at end of parameter list */
+ if (argc ap_php_optind !script_file !exec_direct
strcmp(argv[ap_php_optind-1],--)) {
+ script_file=argv[ap_php_optind];
+ }
+
CG(interactive) = interactive;
- SG(request_info).argc=argc-ap_php_optind;
- SG(request_info).argv=argv+ap_php_optind;
- if (argc ap_php_optind) {
- script_file=argv[ap_php_optind];
+ /* before registering argv to modulule exchange the *new*
argv[0] */
+ /* we can achieve this without allocating more memory */
+ SG(request_info).argc=argc-ap_php_optind+1;
+ arg_excp = argv+ap_php_optind-1;
+ arg_free = argv[ap_php_optind-1];
+ if (script_file) {
+ argv[ap_php_optind-1] = script_file;
+ } else {
+ argv[ap_php_optind-1] = -; /* should be stdin */
}
+ SG(request_info).argv=argv+ap_php_optind-1;
if (php_request_startup(TSRMLS_C)==FAILURE) {
php_module_shutdown(TSRMLS_C);
+ *arg_excp = arg_free;
return FAILURE;
}
+ *arg_excp = arg_free; /* reconstuct argv */
if (no_headers) {
SG(headers_sent) = 1;
SG(request_info).no_headers = 1;
@@ -535,6 +557,7 @@
Re: [PHP-DEV] Re: Have you seen the PHP audit project?
Hi, A PHP auditing project is a good idea, cause there are still lots of bugs, BUT such a project should never ever be led by people from the OpenBSD world. It would be much better if we create our own auditing team. This would ensure that we have control over the bugs that are found and we will never get such arrogant messages like: This bug was fixed in PHP hardening patch about a year ago. Exactly this happened with the SSH deattack hole. Stefan Esser -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
Shane wrote: I think dl is an extremely important feature, and issues surrounding it should be fixed. I'm absolutely, positively +1 on this. On the Mac OS X side of things, we are in the interesting situation of having PHP bundled with the operating system. I guess the same can be said about various Linux distributions, but there is a crucial difference: On the Mac, there is a tremendous pressure to leave the Apple-supplied software alone -- this will guarantee that it will remain upgradeable with Apple's Software Update mechanism, for example. Now Apple obviously can't bundle each and every PHP extension on the operating system CD-ROMs and preconfigured Macs. Currently, this is a lose-lose situation: The Apple-supplied PHP version doesn't have the features you need, and if you replace it with a homegrown PHP, you lose Apple's automatic updates and support. Having a good, working dl mechanism is the only reasonable way out of this Catch-22. Marko -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP audit project
Hello. This is Frank from the PHP audit project. Here are some clarifications. We are working on PHP 4.1.2 because we want to quickly release a patch with basic hardening. Because of the recent vulnerabilities discovered by Stefan, chances are that a lot of kiddies are also auditing the source code with other goals. So we want to release something against the current stable release in order to decrease the chances of new immediate exploits. We just have started the work. There are still plenty of things to be done. As our patches are moving targets and as we don't have a CVS server to work with, things aren't splitted in multiple simple patches yet. But as soon as the 4.1.2 audit will be completed, we will split up everything as small patches in order to submit them to PHP developpers. Then we will work on -HEAD. The goal is to help the PHP developpement, not to keep the patches separate, only for OpenBSD. There are some OpenBSD enhancements, but they are all surrounded with #ifdef __OpenBSD__ . We don't want to break portability, nor to release something only for OpenBSD. The patches are there to be shared by everyone. FYI, I'm working on them on my Linux laptop. The PHP source code is great. We didn't find really bad things so far. There are suspicious parts, but we don't have verified that they really are vulnerable, because we only are at stage 1 of the audit, and we didn't review these parts in their global context. If we verify a flaw, we _will_ immediately let you know. Best regards, -Frank. -- __ /*- Frank DENIS (Jedi/Sector One) [EMAIL PROTECTED] -*\ __ \ '/a href=http://www.PureFTPd.Org/; Secure FTP Server /a\' / \/ a href=http://www.Jedi.Claranet.Fr/; Misc. free software /a \/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Can't build sapi/cgi
Shane Caraveo wrote: I just fixed the problem with that, sorry. No problem. I just fixed a warning in libfcgi, but I'm still getting the following warnings: LINK: warning LNK4049: Locally defined symbol _FCGX_PutStr imported LINK: warning LNK4049: Locally defined symbol _FCGX_IsCGI imported LINK: warning LNK4049: Locally defined symbol _FCGX_FFlush imported LINK: warning LNK4049: Locally defined symbol _FCGX_GetStr imported LINK: warning LNK4049: Locally defined symbol _FCGX_Finish imported LINK: warning LNK4049: Locally defined symbol _FCGX_Accept imported -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.1.2 for windows
Ah, sorry - didn't notice it :) Mail would be fine (just keep php-dev@ OFF the recipient list :) Zeev At 12:32 11/03/2002, Daniel Beulshausen wrote: At 10:31 11.03.2002 +0200, Zeev Suraski wrote: The reason we wanted to wait for Daniel is that he always builds the Windows binaries, and binaries created on other systems might have quirks or dependencies. If he doesn't show up today, I'll use the old 4.1.2 vanilla binaries he sent me a week ago. It won't be with the new Windows fixes, but it'll be on par with the UNIX 4.1.2. i can send them to you per email, as i've got no other place to upload them. ( as said in my other email :) ) daniel /*-- Daniel Beulshausen - [EMAIL PROTECTED] Using PHP on Windows? http://www.php4win.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP audit project
On Mon, 11 Mar 2002, Jedi/Sector One wrote: The goal is to help the PHP developpement, not to keep the patches separate, only for OpenBSD. There are some OpenBSD enhancements, but they are all surrounded with #ifdef __OpenBSD__ . We don't want to break portability, nor to release something only for OpenBSD. The patches are there to be shared by everyone. FYI, I'm working on them on my Linux laptop. Are the strlcpy and strlcat functions (used in the patches) available on Linux? -\- David Eriksson -/- I personally refuse to use inferior tools because of ideology. - Linus Torvalds -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP audit project
On Mon, 11 Mar 2002, David Eriksson wrote: On Mon, 11 Mar 2002, Jedi/Sector One wrote: The goal is to help the PHP developpement, not to keep the patches separate, only for OpenBSD. There are some OpenBSD enhancements, but they are all surrounded with #ifdef __OpenBSD__ . We don't want to break portability, nor to release something only for OpenBSD. The patches are there to be shared by everyone. FYI, I'm working on them on my Linux laptop. Are the strlcpy and strlcat functions (used in the patches) available on Linux? [derick@kossu derick]$ man strlcpy No manual entry for strlcpy [derick@kossu derick]$ man strlcat No manual entry for strlcat Derick -\- David Eriksson -/- I personally refuse to use inferior tools because of ideology. - Linus Torvalds -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Site Resource Manager - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP audit project
On Mon, Mar 11, 2002 at 01:17:07PM +0100, [EMAIL PROTECTED] wrote: Are the strlcpy and strlcat functions (used in the patches) available on Linux? [derick@kossu derick]$ man strlcpy No manual entry for strlcpy [derick@kossu derick]$ man strlcat No manual entry for strlcat PHP defines them if they don't exist. It's in main/strlcpy.c and main/strlcat.c -- __ /*- Frank DENIS (Jedi/Sector One) [EMAIL PROTECTED] -*\ __ \ '/a href=http://www.PureFTPd.Org/; Secure FTP Server /a\' / \/ a href=http://www.Jedi.Claranet.Fr/; Misc. free software /a \/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP audit project
On Mon, Mar 11, 2002 at 01:21:02PM +0100, Stefan Esser wrote: strlcpy and strlcat are inventions of the OpenBSD project. Since they invented those they are trying to infect other projects. PHP is already infected. Try to grep for strlcpy and strlcat in the _vanilla_ PHP source code. But that's ok. If you don't want us to work on PHP, let our project stop. -- __ /*- Frank DENIS (Jedi/Sector One) [EMAIL PROTECTED] -*\ __ \ '/a href=http://www.PureFTPd.Org/; Secure FTP Server /a\' / \/ a href=http://www.Jedi.Claranet.Fr/; Misc. free software /a \/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP audit project
Hi, PHP is already infected. Sorry, my fault. I have overseen that. I just wanted to clearify what strlcat and strlcpy are. I dislike OpenBSD because of several reasons but this list is not the right place to discuss anything like this. But that's ok. If you don't want us to work on PHP, let our project stop. I don't have anything against you guys working on PHP. Four eyes do always see more than two and in the end i think our both interest is a secure PHP. Stefan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP audit project
Frank, Don't be discouraged by the feedback here. Your efforts are well appreciated! You can choose to use whichever functions you deem best, as long as you're the one doing the work :) Zeev At 02:23 PM 3/11/2002, Jedi/Sector One wrote: On Mon, Mar 11, 2002 at 01:21:02PM +0100, Stefan Esser wrote: strlcpy and strlcat are inventions of the OpenBSD project. Since they invented those they are trying to infect other projects. PHP is already infected. Try to grep for strlcpy and strlcat in the _vanilla_ PHP source code. But that's ok. If you don't want us to work on PHP, let our project stop. -- __ /*- Frank DENIS (Jedi/Sector One) [EMAIL PROTECTED] -*\ __ \ '/a href=http://www.PureFTPd.Org/; Secure FTP Server /a\' / \/ a href=http://www.Jedi.Claranet.Fr/; Misc. free software /a \/ -- 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] php-4.1.2 compile error with gd
Hi, I'm about to compile the 4.1.2 version found on php.net. I have the following configure command: ./configure --with-apache=../apache_1.3.23 --with-mysql --with-jpeg-dir=/usr/lib --with-png-dir=/usr/lib --with-zlib-dir --with-freetype-dir --with-gd --enable-gd-native-ttf --with-tiff-dir --with-dom --with-mnogosearch --with-pdflib --with-ftp --enable-gd-imgstrttf --with-gettext The configurepart runs fine. But when I get to the makepart i get the following when its doing something with gd: Making all in gd make[2]: Entering directory `/opt/install/php-4.1.2/ext/gd' make[3]: Entering directory `/opt/install/php-4.1.2/ext/gd' gcc -I. -I/opt/install/php-4.1.2/ext/gd -I/opt/install/php-4.1.2/main -I/opt/install/php-4.1.2 -I/opt/install/apache_1.3.23/src/include -I/opt/install/apache_1.3.23/src/os/unix -I/opt/install/php-4.1.2/Zend -I/usr/local/include/freetype2/freetype -I/usr/local/mnogosearch/include -I/opt/install/php-4.1.2/ext/mysql/libmysql -I/opt/install/php-4.1.2/ext/xml/expat -I/opt/install/php-4.1.2/TSRM -g -O2 -c gd.c touch gd.lo gd.c: In function `zm_startup_gd': gd.c:271: `gdArc' undeclared (first use in this function) gd.c:271: (Each undeclared identifier is reported only once gd.c:271: for each function it appears in.) gd.c:272: `gdPie' undeclared (first use in this function) gd.c:273: `gdChord' undeclared (first use in this function) gd.c:274: `gdNoFill' undeclared (first use in this function) gd.c:275: `gdEdged' undeclared (first use in this function) gd.c: In function `zif_imagecreatetruecolor': gd.c:556: warning: assignment makes pointer from integer without a cast gd.c: In function `zif_imagecolorat': gd.c:1594: structure has no member named `tpixels' make[3]: *** [gd.lo] Error 1 make[3]: Leaving directory `/opt/install/php-4.1.2/ext/gd' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/opt/install/php-4.1.2/ext/gd' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/opt/install/php-4.1.2/ext' make: *** [all-recursive] Error 1 [root@localhost php-4.1.2]# The gdlib thats compiled is gd2.01 and is linked with freetype 2.0.5. It might be worth to mention, if I try the same configure command on php version 4.0.6 it makes fine. I compared /ext/gd from the 4.1.2 and 4.0.6 and seems to be some difference. Does anyone know a soloution to this? Feel free to contact me if you need more information to solve this. Best regards, Eric -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Segfault in do_inherit_parent_constructor
Hi, I am not sure, if this is an error in my code or a PHP error. Whatever, I need help on this. I have created (and attached) a small demonstration extension module, named ctest. This module creates three classes. class1 is the base class, class2 is derived from class1 and class3 is derived from class2. class2 and class1 have some dummy methods, class1 has a constructor. I have used PHP 4.1.2 and compiled it in that way: # ./buildconf # ./configure --enable-ctest # make and if I now call the compiled php binary, I get a segfault. The module is working if I modify one of the following stuff: * Remove the constructor of class1 * Remove one of the dummy methods from class1 or class2. * Remove class3 I tracked down the segfault (by using ddd) to the function do_inherit_parent_constructor. I think this function is called to copy the constructor from the base class to the derived class. class2 is processed correctly. The constructor from class1 is now the constructor of class2. But in the second call to this function, where the constructor from class2 is copied to class3, php crashes while trying to read some stuff from the HashTable of class2. Any idea what's going wrong here? Is there an error in my code or have I encountered a bug in PHP? -- Bye, K http://www.ailis.de/~k/ [A735 47EC D87B 1F15 C1E9 53D3 AA03 6173 A723 E391] (Finger [EMAIL PROTECTED] to get public key) ctest.tar.gz Description: GNU Zip compressed data -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 4.1.2 for windows
Hi, we are waiting for the person who normally builds win32 to release his build. james -Original Message- From: Gabor Hojtsy [mailto:[EMAIL PROTECTED]] Sent: Monday, March 11, 2002 7:43 AM To: [EMAIL PROTECTED] Subject: [PHP-DEV] PHP 4.1.2 for windows Hi! From hour to hour we receive questions at [EMAIL PROTECTED] about the availability of PHP 4.1.2 for Windows. First I tried to give an estimate, but now I don't know what to say. Will there ever be a PHP 4.1.2 for windows, or a 4.1.3??? Guys are waiting for the security fix... Why to kick out windows users from installing a more secure version of PHP? Goba -- 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] cvs server: waiting for cvs's lock in /repository/php4/ext/domxml since hours :)
Hi I wanted to commit some stuff, but i get cvs server: [10:34:25] waiting for cvs's lock in /repository/php4/ext/domxml since hours. Anyone an idea, what's wrong? chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Call overridden methods with call_user_function_ex()
Hi, I have written an simple extension module with two classes. Class A implements the Method dosomething(). Class B is derived from Class A and overrides the method dosomething(). Now I want the overridden method in Class B to call the original method from Class A. How can I do this with call_user_function_ex()? This is easy for constructors, because the constructor of class B has a different name then the constructor of class A, but if I try this with a normal method I have to specify WHICH incarnation of the method should be called or otherwise I get a loop. How can I do this? -- Bye, K http://www.ailis.de/~k/ [A735 47EC D87B 1F15 C1E9 53D3 AA03 6173 A723 E391] (Finger [EMAIL PROTECTED] to get public key) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Can't build sapi/cgi
Hmm, I just downloaded cvs onto a 'clean' machine (doesn't have any fastcgi sources anywhere, other than php cvs) and had no problem compiling. I have seen simular messages before on another project, due to a lack of the define FCGI_STATIC (see fcgiapp.h) in the project. This was added in one of my cvs commits, to all the build configurations, but I missed Release_TSDbg, is that what you are compiling with? I'll be commiting a patch for that in a few moments. Shane - Original Message - From: Sebastian Bergmann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, March 11, 2002 12:01 AM Subject: Re: [PHP-DEV] Can't build sapi/cgi Shane Caraveo wrote: I just fixed the problem with that, sorry. No problem. I just fixed a warning in libfcgi, but I'm still getting the following warnings: LINK: warning LNK4049: Locally defined symbol _FCGX_PutStr imported LINK: warning LNK4049: Locally defined symbol _FCGX_IsCGI imported LINK: warning LNK4049: Locally defined symbol _FCGX_FFlush imported LINK: warning LNK4049: Locally defined symbol _FCGX_GetStr imported LINK: warning LNK4049: Locally defined symbol _FCGX_Finish imported LINK: warning LNK4049: Locally defined symbol _FCGX_Accept imported -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- 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
Re: [PHP-DEV] Can't build sapi/cgi
Shane Caraveo wrote: commits, to all the build configurations, but I missed Release_TSDbg, is that what you are compiling with? No, I'm building Release_TS_Inline. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Apache 2 and PHP 4 (current CVS)
/usr/src/php4/sapi/apache2filter/sapi_apache2.c:473: 'AP_FTYPE_CONTENT' undeclared (first use in this function) -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
At 11:42 11/03/2002 +0200, Marko Karppinen wrote: Shane wrote: I think dl is an extremely important feature, and issues surrounding it should be fixed. I'm absolutely, positively +1 on this. On the Mac OS X side of things, we are in the interesting situation of having PHP bundled with the operating system. I guess the same can be said about various Linux distributions, but there is a crucial difference: On the Mac, there is a tremendous pressure to leave the Apple-supplied software alone -- this will guarantee that it will remain upgradeable with Apple's Software Update mechanism, for example. Now Apple obviously can't bundle each and every PHP extension on the operating system CD-ROMs and preconfigured Macs. Currently, this is a lose-lose situation: The Apple-supplied PHP version doesn't have the features you need, and if you replace it with a homegrown PHP, you lose Apple's automatic updates and support. Having a good, working dl mechanism is the only reasonable way out of this Catch-22. Apple should be using php.ini for extensions and not require the user to call dl() wich is sucky. I still am not quite sure why it's such a big deal to add shared extensions to php.ini. I don't agree that PHP extensions necessarily require dl(). There are many programs out there in the computer industry (such as Apache) which require you to add extensions in an INI file. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
On Mon, Mar 11, 2002 at 08:49:11PM +0200, Andi Gutmans wrote : At 11:42 11/03/2002 +0200, Marko Karppinen wrote: Shane wrote: I think dl is an extremely important feature, and issues surrounding it should be fixed. I'm absolutely, positively +1 on this. On the Mac OS X side of things, we are in the interesting situation of having PHP bundled with the operating system. I guess the same can be said about various Linux distributions, but there is a crucial difference: On the Mac, there is a tremendous pressure to leave the Apple-supplied software alone -- this will guarantee that it will remain upgradeable with Apple's Software Update mechanism, for example. Now Apple obviously can't bundle each and every PHP extension on the operating system CD-ROMs and preconfigured Macs. Currently, this is a lose-lose situation: The Apple-supplied PHP version doesn't have the features you need, and if you replace it with a homegrown PHP, you lose Apple's automatic updates and support. Having a good, working dl mechanism is the only reasonable way out of this Catch-22. Apple should be using php.ini for extensions and not require the user to call dl() wich is sucky. I still am not quite sure why it's such a big deal to add shared extensions to php.ini. I don't agree that PHP extensions necessarily require dl(). There are many programs out there in the computer industry (such as Apache) which require you to add extensions in an INI file. Hehe .. yeah, but then, apache isn't that often used as a scripting language from the command line X-) - Markus -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP audit project
At 13:21 11/03/2002 +0100, Stefan Esser wrote: Hi, strlcpy and strlcat are inventions of the OpenBSD project. Since they invented those they are trying to infect other projects. I added them to PHP a long time ago and I have nothing to do with the OpenBSD project. They are extremely useful functions and should be used instead of strcat()/strcpy(). In Zend we only use memcpy()/memcmp() but for many uses strlcpy()/strlcat() are sufficient. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP audit project
And as long as you don't use strncpy() Just kidding :) Andi At 15:31 11/03/2002 +0200, Zeev Suraski wrote: Frank, Don't be discouraged by the feedback here. Your efforts are well appreciated! You can choose to use whichever functions you deem best, as long as you're the one doing the work :) Zeev At 02:23 PM 3/11/2002, Jedi/Sector One wrote: On Mon, Mar 11, 2002 at 01:21:02PM +0100, Stefan Esser wrote: strlcpy and strlcat are inventions of the OpenBSD project. Since they invented those they are trying to infect other projects. PHP is already infected. Try to grep for strlcpy and strlcat in the _vanilla_ PHP source code. But that's ok. If you don't want us to work on PHP, let our project stop. -- __ /*- Frank DENIS (Jedi/Sector One) [EMAIL PROTECTED] -*\ __ \ '/a href=http://www.PureFTPd.Org/; Secure FTP Server /a\' / \/ a href=http://www.Jedi.Claranet.Fr/; Misc. free software /a \/ -- 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 Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
Having a good, working dl mechanism is the only reasonable way out of this Catch-22. Apple should be using php.ini for extensions and not require the user to call dl() wich is sucky. This is not about what Apple should be doing; indeed, Apple does nothing to stop you from using a php.ini file. The question is this: what will the *users* of Apple computers be doing? For them, digging into the guts of the system, installing PHP extensions there and modifying obscure, Apple-supplied configuration files is MUCH, MUCH more frightening than just downloading a php extension, dropping it into the Sites folder in their home directory, and calling dl(extension.bundle); in their PHP scripts. The fact that we're bundled on OS X has the promise of making PHP available to a whole new group of users. Leveraging that will require special consideration from us. Mac users don't become UNIX users just by installing OS X, and we shouldn't expect them to. --Marko -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
Apple should be using php.ini for extensions and not require the user to call dl() wich is sucky. I still am not quite sure why it's such a big deal to add shared extensions to php.ini. I don't agree that PHP extensions necessarily require dl(). There are many programs out there in the computer industry (such as Apache) which require you to add extensions in an INI file. ?? Perhaps I'm confused here, but using dl() or calling a module in the php.ini file is handled in approximately the same way. In one, the module is loaded at the start, and unloaded when PHP is stopped. And in two, the module is loaded by the script and unloaded when the script is finished. No matter what, you'll still have to use dlopen, dlsym, dlclose to accomplish this. Apple provides emulation dlopen, dlsym, dlclose wrappers for their functions to load dynamic shared objects. Just patching that apple-provided source into the PHP distribution should be fairly painless, and resolve all these issues. I could look into doing this if someone hasn't already in CVS. The one thing to remember is that MACH-O kernel differentiates between a library that is linked and a library that is dynamically opened. Hence *.dylib vs *.so ... AFAIK the APPLE OS X is the only OS that does this, it's a real PITA. - Brad House Sr. Developer Main Street Softworks, Inc. [EMAIL PROTECTED] (352) 378-8228 - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
At 21:08 11/03/2002 +0200, Marko Karppinen wrote: Having a good, working dl mechanism is the only reasonable way out of this Catch-22. Apple should be using php.ini for extensions and not require the user to call dl() wich is sucky. This is not about what Apple should be doing; indeed, Apple does nothing to stop you from using a php.ini file. The question is this: what will the *users* of Apple computers be doing? For them, digging into the guts of the system, installing PHP extensions there and modifying obscure, Apple-supplied configuration files is MUCH, MUCH more frightening than just downloading a php extension, dropping it into the Sites folder in their home directory, and calling dl(extension.bundle); in their PHP scripts. The fact that we're bundled on OS X has the promise of making PHP available to a whole new group of users. Leveraging that will require special consideration from us. Mac users don't become UNIX users just by installing OS X, and we shouldn't expect them to. I'm surprised that MAC OS X's installation/update program doesn't know how to edit text files :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
At 14:03 11/03/2002 -0500, Brad House wrote: Apple should be using php.ini for extensions and not require the user to call dl() wich is sucky. I still am not quite sure why it's such a big deal to add shared extensions to php.ini. I don't agree that PHP extensions necessarily require dl(). There are many programs out there in the computer industry (such as Apache) which require you to add extensions in an INI file. ?? Perhaps I'm confused here, but using dl() or calling a module in the php.ini file is handled in approximately the same way. In one, the module is loaded at the start, and unloaded when PHP is stopped. And in two, the module is loaded by the script and unloaded when the script is finished. The problem isn't MAC OS X. The problem is that PHP's dl() call has certain problems and it is especially hard to get it working in multi-threaded builds. Personally I don't have very much motivation to fix it because I think it sucks anyway :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
At 11:42 11/03/2002 +0200, Marko Karppinen wrote: Shane wrote: I think dl is an extremely important feature, and issues surrounding it should be fixed. I'm absolutely, positively +1 on this. On the Mac OS X side of things, we are in the interesting situation of Apple should be using php.ini for extensions and not require the user to call dl() wich is sucky. I still am not quite sure why it's such a big deal to add shared extensions to php.ini. I don't agree that PHP extensions necessarily require dl(). There are many programs out there in the computer industry (such as Apache) which require you to add extensions in an INI file. I don't see this as an Apple issue at all, though from the comments I guess it could fix an issue for that platform as well. The issue to me is a matter of usability. I want to have a single installation of PHP, but may have many different situations under which I use that installation. Perhaps one application uses modules x, y and z extensively, another uses a, b and c extensively, and perhaps d very rarely. Lets say neither uses extensions the other app uses. The current situation is that I must load all extensions in php.ini irregardless of use, or I must use -c to specify an ini file, etc. I prefer not to load extensions unless I really need them, but PHP simply does not provide an easy effective means to do that. Perl and Python both do and you never have to think about messing with an ini file. I think far PHP has put far too much reliance on the ini file. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Can't build sapi/cgi
You don't by any chance have the fastcgi library from fastcgi.com installed also do you? I simply cannot reproduce the same warnings here. Shane - Original Message - From: Sebastian Bergmann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, March 11, 2002 10:36 AM Subject: Re: [PHP-DEV] Can't build sapi/cgi Shane Caraveo wrote: commits, to all the build configurations, but I missed Release_TSDbg, is that what you are compiling with? No, I'm building Release_TS_Inline. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- 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
Re: [PHP-DEV] the dl() issue
At 10:25 PM 3/11/2002, Shane Caraveo wrote: I prefer not to load extensions unless I really need them Why? If it's performance or stability, than the loss you're paying is roughly 100x more than what you're gaining (yes, it's another one of those out-of-the-pocket numbers, meaning 'a hell of a lot more' :) I don't even want to begin to think about the security implications of this function. Seriously people, please go back to the archives. This dl() issue was discussed in and out about a year ago, and it's been deprecated. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
At 12:25 11/03/2002 -0800, Shane Caraveo wrote: At 11:42 11/03/2002 +0200, Marko Karppinen wrote: Shane wrote: I think dl is an extremely important feature, and issues surrounding it should be fixed. I'm absolutely, positively +1 on this. On the Mac OS X side of things, we are in the interesting situation of Apple should be using php.ini for extensions and not require the user to call dl() wich is sucky. I still am not quite sure why it's such a big deal to add shared extensions to php.ini. I don't agree that PHP extensions necessarily require dl(). There are many programs out there in the computer industry (such as Apache) which require you to add extensions in an INI file. I don't see this as an Apple issue at all, though from the comments I guess it could fix an issue for that platform as well. The issue to me is a matter of usability. I want to have a single installation of PHP, but may have many different situations under which I use that installation. Perhaps one application uses modules x, y and z extensively, another uses a, b and c extensively, and perhaps d very rarely. Lets say neither uses extensions the other app uses. The current situation is that I must load all extensions in php.ini irregardless of use, or I must use -c to specify an ini file, etc. I prefer not to load extensions unless I really need them, but PHP simply does not provide an easy effective means to do that. Perl and Python both do and you never have to think about messing with an ini file. I think far PHP has put far too much reliance on the ini file. I don't know many production installations where all extensions wouldn't be dl()'ed within a few seconds even if there are what you call *rarely* used scripts. I think your examples are theoretical and the ini change can be done quite easily even by a dumb automatic installation script. In any case, I still think a solution can be found I just don't have any concrete ideas on how to fix it. By the way, you mentioned perl as an example. I have no idea how perl works in multi-threaded environments but if you say it works very nicely with perl multi-threaded servers then I take your word for it. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Can't build sapi/cgi
Shane Caraveo wrote: You don't by any chance have the fastcgi library from fastcgi.com installed also do you? No. I simply cannot reproduce the same warnings here. I'm using MS VisualStudio 98, ServicePack 5, btw. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP and UTF
Has it ever been disscuesd to make php support different char encodings internally? - Brad __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] a plead
I know that we are past the freeze date for PHP_4_2_0 but I hope that you can find an exception for this case. Recently the DOM XML interface has received a great deal of attention from the developers and for this reason has moved much closer to completeness. After doing a fair amount of testing on it I have found it to be very stable and quite reliable. The version that is going to ship with 4.2.0 is more or less complete for the average user. However, there is one major hole that I just don't see how you can allow to slip past. Up until about 3 days ago, the function remove_attribute() had not yet been implemented. From what I can tell, it was simply overlooked and of all the functions that are still not implemented, it is by far the most important, since it blocks a very fundamental usage of the module, one surely everyone using it will need. It is currently implemented but missed the 4_2_0 branch. On top of that argument, I just finished and submitted an entire PEAR interface to act as a frontend for the DOM XML/XPATH module and this one missing function is going to put off the usefullness of it for yet another release. Please find it in your programming hearts to allow remove_attribute() to make it into 4_2_0. Thanks, Dan Allen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] a plead
+1 On Mon, Mar 11, 2002 at 02:23:32PM -0800, Dan Allen wrote : I know that we are past the freeze date for PHP_4_2_0 but I hope that you can find an exception for this case. Recently the DOM XML interface has received a great deal of attention from the developers and for this reason has moved much closer to completeness. After doing a fair amount of testing on it I have found it to be very stable and quite reliable. The version that is going to ship with 4.2.0 is more or less complete for the average user. However, there is one major hole that I just don't see how you can allow to slip past. Up until about 3 days ago, the function remove_attribute() had not yet been implemented. From what I can tell, it was simply overlooked and of all the functions that are still not implemented, it is by far the most important, since it blocks a very fundamental usage of the module, one surely everyone using it will need. It is currently implemented but missed the 4_2_0 branch. On top of that argument, I just finished and submitted an entire PEAR interface to act as a frontend for the DOM XML/XPATH module and this one missing function is going to put off the usefullness of it for yet another release. Please find it in your programming hearts to allow remove_attribute() to make it into 4_2_0. Thanks, Dan Allen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
The issue to me is a matter of usability. I want to have a single installation of PHP, but may have many different situations under which I use that installation. Perhaps one application uses modules x, y and z extensively, another uses a, b and c extensively, and perhaps d very rarely. Lets say neither uses extensions the other app uses. The current situation is that I must load all extensions in php.ini irregardless of use, or I must use -c to specify an ini file, etc. I prefer not to load extensions unless I really need them, but PHP simply does not provide an easy effective means to do that. Perl and Python both do and you never have to think about messing with an ini file. I think far PHP has put far too much reliance on the ini file. I don't know many production installations where all extensions wouldn't be dl()'ed within a few seconds even if there are what you call *rarely* used scripts. I think your examples are theoretical and the ini change can be done quite easily even by a dumb automatic installation script. Only as theoretical as the arguments against dl appear to me, and it doesn't matter if all dl()'d libraries are loaded right away, it matters that dl is extremely more flexible than dealing with php.ini. It's funny, I recall being the one to want php.ini for php3. Now I find it the single most frustrating thing about php. In any case, I still think a solution can be found I just don't have any concrete ideas on how to fix it. Thus why I wanted to reopen this discussion. I think a solution can be found, and I don't feel it's right to shut out the issue because a 'solution' exists in the ini file, or because of unexplained claims of performance, stability and security issues. Without real thought on it, and a real explaination of the issues, no solution will be found. The only valid explaination I found was that the module init ends up getting called twice, resulting in a performance issue. There was something else about garbage collection of classes. That kind of information is the kind that is important to know. Concrete issues are fixable. Of course loading libraries at run time are going to be slower performing and non-optimizable in certain situations. Dynamicaly loading anything is, and we dynamicly load everything. I cannot imagin any real concrete reasons against dl. Any previous archive email about dl I read failed to convince me that dl should be deprecated. By the way, you mentioned perl as an example. I have no idea how perl works in multi-threaded environments but if you say it works very nicely with perl multi-threaded servers then I take your word for it. I have worked on a multi-threaded perl server at work (PerlEx). There is no issue with dynamic loading of modules unless, of course, they are not thread safe. Dynamic loaded modules remain loaded until the interpreter is shut down, so there is no performance issue except on the first load. Commonly loaded modules can be preloaded to avoid the initial hit during script execution. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New Build System Committed to HEAD
On Thu, 7 Mar 2002, Sascha Schumann wrote: Hi, you won't see the commit, because it is too large to go through the mailing list. Perhaps it bounced to Jim, so that he can make it available by alternative means. Something in this commit might uncover an autoconf-2.52 portability bug on FreeBSD. I don't know whether this was already earlier the case. Until the autoconf team addresses this issue, I suggest to use autoconf-2.13 on that platform. (Readers of new-httpd might be already familiar with the issue.) Because I cannot test/build every extension under the earth, problems with untested extensions might crop up. If it does, please notify me and I'll check it out. When I try to build pear/PECL/satellite, I get an error like this: [david@natty:/usr/local/satellite-dev/src/pear/PECL/satellite] $ phpize [david@natty:/usr/local/satellite-dev/src/pear/PECL/satellite] $ ./configure ... ./configure: /usr/local/satellite-dev/src/pear/PECL/satellite/ext/satellite/Makefile.in: No such file or directory ... Makefile.in is located in /usr/local/satellite-dev/src/pear/PECL/satellite and not where configure is looking... This error does not appear with PHP 4.1.2. -\- David Eriksson -/- I personally refuse to use inferior tools because of ideology. - Linus Torvalds -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] setup.stub files
do these files serve any purpose any more, or are they just leftover remnants from the old setup script? jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] odbc_execute's file-opening hack
torben's checkin to the documentation reminded me -- why is this gross hack in there, instead of just allowing open filehandles to be passed? the special treatment of strings that begin and end with single quotes just seems like a huge 'wtf?' sort of feature. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: cvs: php4 /ext/pgsql pgsql.c
Yasuo Ohgaki wrote:
yohgaki Mon Mar 11 09:53:59 2002 EDT
Modified files:
/php4/ext/pgsql pgsql.c
Log:
Print function names in error messages
Hi all,
Currently pgsql module's error message is not consistent with other
modules' error message format and does not print function names.
I would like to fix that as follows. (This is only one of them, but
there are many error messages like this)
If you have opinion, please let me know.
Index: php4/ext/pgsql/pgsql.c
diff -u php4/ext/pgsql/pgsql.c:1.153 php4/ext/pgsql/pgsql.c:1.154
--- php4/ext/pgsql/pgsql.c:1.153 Mon Mar 11 02:23:07 2002
+++ php4/ext/pgsql/pgsql.cMon Mar 11 09:53:59 2002
@@ -19,7 +19,7 @@
+--+
*/
-/* $Id: pgsql.c,v 1.153 2002/03/11 07:23:07 yohgaki Exp $ */
+/* $Id: pgsql.c,v 1.154 2002/03/11 14:53:59 yohgaki Exp $ */
#include stdlib.h
@@ -1029,7 +1029,8 @@
convert_to_long_ex(field);
if (Z_LVAL_PP(field) 0 || Z_LVAL_PP(field) = PQnfields(pgsql_result)) {
- php_error(E_WARNING,Bad field offset specified);
+ php_error(E_WARNING,%s() bad field offset specified,
+ get_active_function_name(TSRMLS_C));
RETURN_FALSE;
}
--
Yasuo Ohgaki
[EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: cvs: php4(PHP_4_2_0) /ext/imap php_imap.h
Derick Rethans wrote: derickMon Mar 11 18:11:37 2002 EDT Modified files: (Branch: PHP_4_2_0) /php4/ext/imapphp_imap.h Log: - MFH for bug #16008 Isn't #if ABC #include some.h #else #include other.h #endif is better? I don't know if there is, but I thought some pre processer may not like # include some.h -- Yasuo Ohgaki Index: php4/ext/imap/php_imap.h diff -u php4/ext/imap/php_imap.h:1.17 php4/ext/imap/php_imap.h:1.17.2.1 --- php4/ext/imap/php_imap.h:1.17 Thu Feb 28 03:26:17 2002 +++ php4/ext/imap/php_imap.h Mon Mar 11 18:11:37 2002 -26,7 +26,7 +--+ */ -/* $Id: php_imap.h,v 1.17 2002/02/28 08:26:17 sebastian Exp $ */ +/* $Id: php_imap.h,v 1.17.2.1 2002/03/11 23:11:37 derick Exp $ */ #ifndef PHP_IMAP_H #define PHP_IMAP_H -39,11 +39,11 #if defined(HAVE_IMAP2000) || defined(HAVE_IMAP2001) /* these are used for quota support */ - #include c-client.h /* includes mail.h and rfc822.h */ - #include imap4r1.h/* location of c-client quota functions */ +# include c-client.h /* includes mail.h and rfc822.h */ +# include imap4r1.h/* location of c-client quota functions */ #else - #include mail.h - #include rfc822.h +# include mail.h +# include rfc822.h #endif extern zend_module_entry imap_module_entry; -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] odbc_execute's file-opening hack
On Mon, 11 Mar 2002, Jim Winstead wrote: torben's checkin to the documentation reminded me -- why is this gross hack in there, instead of just allowing open filehandles to be passed? The reaosn is mainly historical, pre-me so I have no idea why. the special treatment of strings that begin and end with single quotes just seems like a huge 'wtf?' sort of feature. It's going to be phased out as I bring ODBC upto v3.5 compatibility... --- Dan KalowskyThe record shows, I took the blows. http://www.deadmime.org/~dankAnd did it my way. [EMAIL PROTECTED]- My Way, Frank Sinatra -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Make php-cvs@ read-only
'lo, could we make the [EMAIL PROTECTED] 'read-only', ie. only the CVS script may write to it? Maybe mails sent to [EMAIL PROTECTED] could be forwarded to the [EMAIL PROTECTED] list. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: cvs: php4 / run-tests.php
Yasuo Ohgaki wrote:
yohgaki Tue Mar 12 00:33:12 2002 EDT
Modified files:
/php4 run-tests.php
Log:
Do not search php binary in search path, since we are not testing older builds.
Print SAPI used.
There is problem with version and sapi name, since it is printing
version and sapi of php binary running run-tests.php script.
i.e.: php binary running each test script may differ
I didn't change the original code, since there is no way
to write script in command like
php -e echo PHP_VERSION
or
php -e ?php echo PHP_VERSION ?
Is there way to do that now?
--
Yasuo Ohgaki
Index: php4/run-tests.php
diff -u php4/run-tests.php:1.35 php4/run-tests.php:1.36
--- php4/run-tests.php:1.35 Tue Mar 12 00:18:25 2002
+++ php4/run-tests.phpTue Mar 12 00:33:03 2002
@@ -170,9 +170,10 @@
} elseif (@is_executable(./sapi/cli/php{$ext})) {
$php = getcwd() . /sapi/cli/php{$ext};
}
-if (empty($php)) {
-$php = in_path(php, $windows_p);
-}
+// Test result can be bogus, if we use php binary in path. - [EMAIL PROTECTED]
+// if (empty($php)) {
+// $php = in_path(php, $windows_p);
+// }
if (empty($php)) {
dowriteln(Unable to find PHP executable (php{$ext}).);
dowriteln(Please build PHP as a CGI executable or make sure it is);
@@ -283,7 +284,8 @@
dowriteln(sprintf(Tests passed: %4d (%s%%), $passed, $passed_pstr));
dowriteln(=);
dowriteln(Skipped .sizeof($skipped_extensions). extensions.);
-dowriteln(PHP Version: .phpversion());
+ dowriteln(PHP SAPI: .PHP_SAPI);
+dowriteln(PHP Version: .PHP_VERSION);
}
function find_testdirs($dir = '.', $first_pass = true)
--
Yasuo Ohgaki
[EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Make php-cvs@ read-only
we can set the reply-to to be php-dev@ ... that would certainly go a long way. James -Original Message- From: Sebastian Bergmann [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 12, 2002 6:04 AM To: [EMAIL PROTECTED] Subject: [PHP-DEV] Make php-cvs@ read-only 'lo, could we make the [EMAIL PROTECTED] 'read-only', ie. only the CVS script may write to it? Maybe mails sent to [EMAIL PROTECTED] could be forwarded to the [EMAIL PROTECTED] list. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- 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] Text files in /php4
I wanted to get some discussion going about making the php4 tree less cluttered. The first thing to do, I think, is to move the documentation out from the root directory. Therefore, i'd like to propose the following: /php4/ NEWS CREDITS INSTALL LICENSE TODO.BUILDv5 TODO EXTENSIONS php.ini-dist php.ini-recommended /php4/docs/ README.Zeus README.ZEUS README.SELF-CONTAINED-EXTENSIONS README.CVS-RULES README.TESTING README.EXTENSIONS README.PARAMETER_PARSING_API README.STREAMS README.QNX README.EXT_SKEL RELEASE_PROCESS CODING_STANDARDS apidoc-zend.txt APIDOC_ZEND apidoc.txt APIDOC ChangeLog.1999.gz ChangeLog.2001.gz ChangeLog.2000.gz It might be nice -- and much easier then -- to convert these document files into phpdoc format, and update them in the manual too. James -- James Cox :: [EMAIL PROTECTED] :: Landonize It! http://landonize.it/ Was I helpful? http://www.amazon.co.uk/exec/obidos/wishlist/23IVGHQ61RJGO/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Make php-cvs@ read-only
Please don't start this again. There is no technically valid reason to destroy mail headers on mailing lists, especially lists geared at supposedly technically adept users. -Rasmus On Tue, 12 Mar 2002, James Cox wrote: we can set the reply-to to be php-dev@ ... that would certainly go a long way. James -Original Message- From: Sebastian Bergmann [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 12, 2002 6:04 AM To: [EMAIL PROTECTED] Subject: [PHP-DEV] Make php-cvs@ read-only 'lo, could we make the [EMAIL PROTECTED] 'read-only', ie. only the CVS script may write to it? Maybe mails sent to [EMAIL PROTECTED] could be forwarded to the [EMAIL PROTECTED] list. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- 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 Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Can't build sapi/cgi
Shane Caraveo wrote: I simply cannot reproduce the same warnings here. The warnings are gone now. Dunny why, though ;) -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: artka
I am going to write a PHP frontend for aspseek search engine. www.aspseek.org. Thanks -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: cvs: php4 / run-tests.php
Yasuo Ohgaki wrote: Yasuo Ohgaki wrote: yohgakiTue Mar 12 00:33:12 2002 EDT Modified files: /php4run-tests.php Log: Do not search php binary in search path, since we are not testing older builds. Print SAPI used. There is problem with version and sapi name, since it is printing version and sapi of php binary running run-tests.php script. i.e.: php binary running each test script may differ I didn't change the original code, since there is no way to write script in command like php -e echo PHP_VERSION or php -e ?php echo PHP_VERSION ? Is there way to do that now? Never mind. CGI version will never support script in command line. I added new file so that run-tests.php print correct PHP version and sapi name always. -- Yasuo Ohgaki [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make php-cvs@ read-only
Rasmus Lerdorf wrote: Please don't start this again. There is no technically valid reason to destroy mail headers on mailing lists, especially lists geared at supposedly technically adept users. Sure, but having dicussions on both php-cvs and php-dev is nasty, IMHO. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make php-cvs@ read-only
It seems to work quite nicely for most. Having the mailing list software remove a user's ability to control where replies go is even nastier. Add to that thet danger of mail loops from badly configured servers. We have gone over this a bunch of times. Yes, it makes users perhaps think just a fraction of a second more if they don't know their mail client software very well, or if their mail client software sucks, but that's fine with me. If ezmlm had a way for users to individually set this for themselves, I wouldn't have a problem with it, but forcing this on everyone after years of being used to private replies unless specifically made public is going to cause countless messages that were not meant to go to the thousands of subscribers. At best this would increase the amount of junk on the list, and at worst this would cause a lot of embarassment for users. -Rasmus On Tue, 12 Mar 2002, Sebastian Bergmann wrote: Rasmus Lerdorf wrote: Please don't start this again. There is no technically valid reason to destroy mail headers on mailing lists, especially lists geared at supposedly technically adept users. Sure, but having dicussions on both php-cvs and php-dev is nasty, IMHO. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- 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] One Makefile to rule them all
Hello Sascha and everyone! No doubt the new build system is faster than the old one. But I miss having one Makefile for each directory. Was that the slow part of the build process? Regards, -\- David Eriksson -/- I personally refuse to use inferior tools because of ideology. - Linus Torvalds -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
