[PHP-DEV] Weird PHP5 APXS libtools errors
From HEAD: ./configure works fine (no options)... Make, everything. But... ./configure --with-apxs=/usr/local/apache/bin/apxs Causes some weirdness on Make... [user@localhost]# make /bin/sh libtool --preserve-dup-deps --mode=compile gcc -I/home/php/php5/ext/mysql/libmysql -Iext/mysql/ -I/home/php/php5/ext/mysql/ -DPHP_ATOM_INC -I/home/php/php5/include -I/home/php/php5/main -I/home/php/php5 -I/home/php/php5/Zend -I/home/php/php5/ext/xml/expat -DLINUX=22 -DUSE_HSREGEX -DUSE_EXPAT -I/home/php/php5/TSRM -g -O2 -prefer-pic -c /home/php/php5/ext/mysql/php_mysql.c -o ext/mysql/php_mysql.lo libtool: s%^.*/%%: No such file or directory libtool: -e: command not found libtool: -e: command not found libtool: -e: command not found libtool: -e: command not found libtool: -e: command not found (more of these) I'm not familiar enough with the build environment as a whole, but I've been building HEAD for quite some time now and I'm not sure why now it'd just choke like thisAny suggestions welcome. John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Weird PHP5 APXS libtools errors
On Thu, 13 Feb 2003, John Coggeshall wrote: I'm not familiar enough with the build environment as a whole, but I've been building HEAD for quite some time now and I'm not sure why now it'd just choke like thisAny suggestions welcome. upgrade your libtool to 1.4.3, it is required now. 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] Weird PHP5 APXS libtools errors
upgrade your libtool to 1.4.3, it is required now. [user@localhost php5]# ./buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4-p5 (ok) buildconf: libtool version 1.4.3 (ok) And just to be sure.. [user@localhost php5]# libtool --version ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) Any other thoughts? If there's anything else you need to know, let me know. John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Weird PHP5 APXS libtools errors
On Thu, 13 Feb 2003, John Coggeshall wrote: upgrade your libtool to 1.4.3, it is required now. [user@localhost php5]# ./buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4-p5 (ok) buildconf: libtool version 1.4.3 (ok) And just to be sure.. [user@localhost php5]# libtool --version ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) Any other thoughts? If there's anything else you need to know, let me know. Does a snapshot from snaps.php.net compile without running ./buildconf? Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Weird PHP5 APXS libtools errors
If output of 'm4 --version' != 'GNU m4 1.4' you need to update it and rebuild autoconf with the working m4. --Jani On Thu, 13 Feb 2003, John Coggeshall wrote: upgrade your libtool to 1.4.3, it is required now. [user@localhost php5]# ./buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4-p5 (ok) buildconf: libtool version 1.4.3 (ok) And just to be sure.. [user@localhost php5]# libtool --version ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) Any other thoughts? If there's anything else you need to know, let me know. John -- - For Sale! - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Weird PHP5 APXS libtools errors
Does a snapshot from snaps.php.net compile without running ./buildconf? Yep it does, actually... I'll investigate further into it when I get some sleep :) John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-DOC] Re: function.main
On Wed, 12 Feb 2003, Gabor Hojtsy wrote: what is function.main? it keeps popping up on my requires and links to = yoru site but nuthin' happens That is if I understand correctly a link in an error message. So either PHP needs to hide that link in error messages, or the function.main shortcut shuold point to somewhere on the homepage, explaining what is function.main This was fixed in CVS awhile ago (4.3.1) and now points to the proper docs. See: http://bugs.php.net/bug.php?id=21499 How was that fixed? Will there be any links with those errors for function.main but for a different page, or no links? I think it would be nice to make http://php.net/function.main show something (preferably the same thing that this fixed error message points to), if applicable... It was fixed in that it will link to documention for include() or require() (depending on the error) instead of main(). So, it links to different yet more appropriate pages now. Not sure if/what other errors cause a link to here but I agree we may as well create a dummy page for main() with some hopefully helpful information. I just comitted main.xml in /info/ so have a look, comments welcome. Regards, Philip -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: function.main
Gabor Hojtsy wrote: That is if I understand correctly a link in an error message. So either PHP needs to hide that link in error messages, or the function.main shortcut shuold point to somewhere on the homepage, explaining what is function.main speaking of the link feature: can't we deactivate that for error_log output? error messages in the logfiles are almost unreadable right now (at least it takes a long time to identify the actual message, esp. on 'file not found' types of messages)? -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 Sie finden uns auf der CeBIT in Halle 6/H44 http://www.six.de/cebit2003/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-DOC] Re: function.main
It was fixed in that it will link to documention for include() or require() (depending on the error) instead of main(). So, it links to different yet more appropriate pages now. Not sure if/what other errors cause a link to here but I agree we may as well create a dummy page for main() with some hopefully helpful information. I just comitted main.xml in /info/ so have a look, comments welcome. Cool. Goba -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: function.main
That is if I understand correctly a link in an error message. So either PHP needs to hide that link in error messages, or the function.main shortcut shuold point to somewhere on the homepage, explaining what is function.main speaking of the link feature: can't we deactivate that for error_log output? error messages in the logfiles are almost unreadable right now (at least it takes a long time to identify the actual message, esp. on 'file not found' types of messages)? If you turn of html_errors, that should turn off that link too IMHO, not tested though... Goba -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Register Shutdown Function for Apache
Thanks Jani. I'll work on getting the patch working on HEAD and PHP_4_3
this afternoon.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Jani Taskinen
Sent: Thursday, February 13, 2003 2:49 AM
To: Brian Moon
Cc: Joseph Tate; Php-Dev List
Subject: Re: [PHP-DEV] Register Shutdown Function for Apache
There is now 'HAVE_APACHE' defined when you configure with apache.
(dso or static)
--Jani
On Tue, 11 Feb 2003, Brian Moon wrote:
Jani, are you volunteering to add it? If so, please do so at
your earliest
convience.
Brian Moon
dealnews.com
- Original Message -
From: Jani Taskinen [EMAIL PROTECTED]
To: Joseph Tate [EMAIL PROTECTED]
Cc: Php-Dev List [EMAIL PROTECTED]
Sent: Monday, February 10, 2003 6:16 PM
Subject: RE: [PHP-DEV] Register Shutdown Function for Apache
|
| If you need a define for it, we can add one..?
|
| --Jani
|
|
| On Mon, 10 Feb 2003, Joseph Tate wrote:
|
| Well, to me, calling the code that flushes the headers and the output
| buffers twice doesn't kill us. Unless someone can come up
with a better
way
| to not call these two functions in
main/main.c::php_request_shutdown, the
| patch suffices for me. MOD_PHP4_H is undefined in main.c, so it's not
| acceptable.
|
| Joseph
|
| -Original Message-
| From: Brian Moon [mailto:[EMAIL PROTECTED]]
| Sent: Monday, February 03, 2003 5:30 PM
| To: Joseph Tate; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
| Cc: Php-Dev List
| Subject: Re: [PHP-DEV] Register Shutdown Function for Apache
|
|
| Hmm, there is #define MOD_PHP4_H in sapi/apache/mod_php4.h.
Not real
| descriptive, but seems to be unique to the Apache sapi.
|
| Brian Moon
| dealnews.com
|
|
| - Original Message -
| From: Joseph Tate [EMAIL PROTECTED]
| To: Brian Moon [EMAIL PROTECTED]; [EMAIL PROTECTED];
| [EMAIL PROTECTED]; [EMAIL PROTECTED]
| Cc: Php-Dev List [EMAIL PROTECTED]
| Sent: Monday, February 03, 2003 3:45 PM
| Subject: Re: [PHP-DEV] Register Shutdown Function for Apache
|
|
| | Here is an updated patch which copies a few of the methods from
| | main/main.c::php_request_shutdown to
| | sapi/apache/sapi_apache.c::apache_php_module_main. This has
| flushed both
| | the headers and output buffers in my two test scripts.
Now I need to
| figure
| | out a way to make sure these don't get called in
| | main/main.c::php_request_shutdown on Apache systems. Any
pointers on
| this?
| | Is there a handy #define that I can use if configure is
| called --with-apxs?
| |
| | Joseph
| |
| | P.S. The two test scripts are:
| |
| | ?PHP
| | header('Location: http://www.mi-corporation.com');
| | exit();
| | ?
| |
| | and
| |
| | ?PHP
| | ob_begin();
| | phpinfo();
| | ?
| |
| | -Original Message-
| | From: Brian Moon [mailto:[EMAIL PROTECTED]]
| | Sent: Tuesday, January 28, 2003 5:50 PM
| | To: [EMAIL PROTECTED]; Joseph Tate
| | Cc: Php-Dev List; PHP Group
| | Subject: Re: [PHP-DEV] Re: Register Shutdown Function for Apache
| |
| |
| | Give me a patch and I will tell you. ;)
| |
| | Brian Moon
| | dealnews.com
| |
| |
| | - Original Message -
| | From: Zeev Suraski [EMAIL PROTECTED]
| | To: Joseph Tate [EMAIL PROTECTED]
| | Cc: Brian Moon [EMAIL PROTECTED]; Php-Dev List
| | [EMAIL PROTECTED]; PHP Group [EMAIL PROTECTED]
| | Sent: Tuesday, January 28, 2003 4:03 PM
| | Subject: RE: [PHP-DEV] Re: Register Shutdown Function for Apache
| |
| |
| | | At 19:54 28/01/2003, Joseph Tate wrote:
| | | Then, could we add a sapi_flush()/ob_flush() call at
the end of
| | | apache_php_module_main after calling the normal
| | register_shutdown_functions?
| | |
| | | Yeah, something along these lines.
| | |
| | | What else might have problems?
| | |
| | | Might is a powerful word :)
| | |
| | | Zeev
| | |
| | |
| | |
| |
| |
| | --
| | PHP Development Mailing List http://www.php.net/
| | To unsubscribe, visit: http://www.php.net/unsub.php
| |
| |
| |
| |
|
|
|
|
|
|
|
| --
| - For Sale! -
|
|
| --
| PHP Development Mailing List http://www.php.net/
| To unsubscribe, visit: http://www.php.net/unsub.php
|
|
|
--
- For Sale! -
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Sun LDAP and ldap_set_rebind_proc
Hi,
I just created a patch for a customer
who needed ldap_set_rebind_proc for
named rebinding on a sun ldap server.
The #if statements are a bit dirty, but i
did not manage to find the correct
ifdef condition.
Maybe someone can use it or even integrate
it into cvs.
If you have any questions regarding this
patch, do not hesitate to contact me.
Greetings
Matthias Lange
--
Matthias Lange, Dipl.-Ing. (FH)
NetUSE AG Dr.-Hell-Straße Fon: +49 431 38643500
http://www.netuse.de/ D-24107 Kiel, Germany Fax: +49 431 38643599
Infos über den neuen NetUSE Workflow Manager: http://workflow.NetUSE.de
*** ldap.c.original Thu Jan 30 17:38:28 2003
--- ldap.c Thu Feb 13 16:11:51 2003
***
*** 61,67
typedef struct {
LDAP *link;
! #if defined(LDAP_API_FEATURE_X_OPENLDAP) defined(HAVE_3ARG_SETREBINDPROC)
zval *rebindproc;
#endif
} ldap_linkdata;
--- 61,67
typedef struct {
LDAP *link;
! #if 1 || defined(LDAP_API_FEATURE_X_OPENLDAP) defined(HAVE_3ARG_SETREBINDPROC)
zval *rebindproc;
#endif
} ldap_linkdata;
***
*** 121,127
PHP_FE(ldap_compare,
NULL)
PHP_FE(ldap_sort,
NULL)
! #if ( LDAP_API_VERSION 2000 ) || HAVE_NSLDAP
PHP_FE(ldap_get_option, third_argument_force_ref)
PHP_FE(ldap_set_option,
NULL)
PHP_FE(ldap_parse_result, arg3to6of6_force_ref)
--- 121,127
PHP_FE(ldap_compare,
NULL)
PHP_FE(ldap_sort,
NULL)
! #if 1 || ( LDAP_API_VERSION 2000 ) || HAVE_NSLDAP
PHP_FE(ldap_get_option, third_argument_force_ref)
PHP_FE(ldap_set_option,
NULL)
PHP_FE(ldap_parse_result, arg3to6of6_force_ref)
***
*** 136,142
#endif
#endif
! #if defined(LDAP_API_FEATURE_X_OPENLDAP) defined(HAVE_3ARG_SETREBINDPROC)
PHP_FE(ldap_set_rebind_proc,NULL)
#endif
--- 136,142
#endif
#endif
! #if 1 || defined(LDAP_API_FEATURE_X_OPENLDAP) defined(HAVE_3ARG_SETREBINDPROC)
PHP_FE(ldap_set_rebind_proc,NULL)
#endif
***
*** 173,179
ldap_linkdata *ld = (ldap_linkdata *)rsrc-ptr;
ldap_unbind_s(ld-link);
! #if defined(LDAP_API_FEATURE_X_OPENLDAP) defined(HAVE_3ARG_SETREBINDPROC)
if (ld-rebindproc != NULL) {
zval_dtor(ld-rebindproc);
FREE_ZVAL(ld-rebindproc);
--- 173,179
ldap_linkdata *ld = (ldap_linkdata *)rsrc-ptr;
ldap_unbind_s(ld-link);
! #if 1 || defined(LDAP_API_FEATURE_X_OPENLDAP) defined(HAVE_3ARG_SETREBINDPROC)
if (ld-rebindproc != NULL) {
zval_dtor(ld-rebindproc);
FREE_ZVAL(ld-rebindproc);
***
*** 508,514
/* deref */
if (deref -1) {
! #if ( LDAP_API_VERSION = 2004 ) || HAVE_NSLDAP
ldap_set_option(ldap, LDAP_OPT_DEREF, deref);
#else
ldap-ld_deref = deref;
--- 508,514
/* deref */
if (deref -1) {
! #if 1 || ( LDAP_API_VERSION = 2004 ) || HAVE_NSLDAP
ldap_set_option(ldap, LDAP_OPT_DEREF, deref);
#else
ldap-ld_deref = deref;
***
*** 2003,2010
#endif /* ( LDAP_API_VERSION 2000 ) || HAVE_NSLDAP */
#if defined(LDAP_API_FEATURE_X_OPENLDAP) defined(HAVE_3ARG_SETREBINDPROC)
! int _ldap_rebind_proc(LDAP *ldap, const char *url, ber_tag_t req, ber_int_t msgid,
void *params) {
ldap_linkdata *ld;
int retval;
zval *cb_url;
--- 2003,2013
#endif /* ( LDAP_API_VERSION 2000 ) || HAVE_NSLDAP */
+ #if (LDAP_API_VERSION = 2004) || HAVE_NSLDAP ||
+defined(LDAP_API_FEATURE_X_OPENLDAP) defined(HAVE_3ARG_SETREBINDPROC)
+
+ int _ldap_rebind_proc
#if defined(LDAP_API_FEATURE_X_OPENLDAP) defined(HAVE_3ARG_SETREBINDPROC)
! (LDAP *ldap, const char *url, ber_tag_t req, ber_int_t msgid,
void *params) {
ldap_linkdata *ld;
int retval;
zval *cb_url;
***
*** 2037,2045
zval_dtor(cb_url);
FREE_ZVAL(cb_url);
return retval;
! }
/* {{{ proto bool ldap_set_rebind_proc(resource link, string callback)
Set a callback function to do re-binds on referral chasing. */
PHP_FUNCTION(ldap_set_rebind_proc)
--- 2040,2129
zval_dtor(cb_url);
FREE_ZVAL(cb_url);
return retval;
! #else
! /**
! * 2003-02-13 Matthias Lange [EMAIL PROTECTED]
!
Re: [PHP-DEV] repost: return_value getting corrupted in extension
On Wed, 12 Feb 2003 13:40:09 -0800, Eric Lambart wrote: UPDATE... If you ask me, this is stranger still. If you recall from my original post-- I am trying to return a serverId object member which contains a value such as N^VESoDMN(107). Again, right before my PHP_FUNCTION returns control to the script, this value is perfect. When I DON'T use --enable-debug, and the serverId is NOT getting completely clobbered, the value that is returned by $table-serverId is not N^VESoDMN(107). It is N^VESoDMN'107) This is not a random thing. It is very consistent--I have several PHP_FUNCTIONs that return serverIds, either with RETVAL_STRING or as a member of a more complex object, and server IDs are always in a similar format, a string ending with a parenthesized integer. Yet EVERY time, the ( is replaced by a single quote. OK, here's an update. I was not entirely correct about the ( becoming ' being some sort of simple character substitution. First of all, I have recompiled my extension under PHP 4.3.0 and the problem persists; exactly the same thing happens. It is therefore not an issue with 4.2.3. I am no longer using --enable-debug since it was not revealing any memory leaks anyway, and the problem with the single-character substitution seemed a little less abstract than the strings getting completely clobbered, as with debug enabled. Second of all, I have narrowed the problem down a bit. It has nothing to do with parentheses or single-quotes (surprise!). Seriously... I just observed it mangling another string, but what seemed stranger yet, it changed \037N^VESOBJ(4) to \037N^VESOBJ(3) (this is output from gdb, so that's ASCII octal 37, which isn't a printable character and didn't show up in my previous console output). So what does this have in common with changing \037N^VESoDMN(107) to \037N^VESoDMN'107)? Simple: it is the 11th character of the string that is getting changed. Moreover, it is getting decremented by one. Just as 3 precedes 4 in the ASCII table, ' precedes ). These strings that are getting mangled are not the same variables... not the same zvals or memory locations or anything. And in the case of 4 becoming 3, the circumstances are completely different. It has nothing (at least directly) to do with my extension functions. The only thing they have in common is the location: ((my zval*)-value-str.val) + 11 Check out this code from my test script: $arrayClass = eo_invoke_method($conn, $objPtr, $method, 0, $params); echo arrayClass='$arrayClass'\n; $method = Interface; echo arrayClass='$arrayClass'\n; $params = array(); echo arrayClass='$arrayClass'\n; Which produces this console output: arrayClass='N^VESOBJ(4)' arrayClass='N^VESOBJ(4)' arrayClass='N^VESOBJ(3)' Now to me, this is really baffling. Right before my variable changes, I am initializing the variable $params to be a new array() object (fwiw, $params already _was_ an array() containing one value; I am just re-using the variable). So, in the process of initializing a standard PHP array(), something in the Zend engine is mangling my seemingly unrelated variable, $arrayClass... and I swear I'm not telling it to! $arrayClass, coincidentally, refers to an object stored on a remote database server, and never contains, nor is ever contained IN, a PHP array. It is just a simple PHP string. Running trusty (?) old gdb, I set read and write watches on $arrayClass-value-str.val, but can't seem to catch where it's changing. The read watch is only triggered by PHP processing each echo statement which displays $arrayClass's value, the write watchpoint is never caught. But what could be doing this? Does the number 11 hold any special significance? And why is the 11th character being decremented? Could Zend be trying to decrement the refcount for something and pointing to the wrong part of memory? I suppose it could be decrementing just about anything, but why the 11th character of several different string-containing zvals? This is obviously not completely random. Please help me before I lose what's left of my mind! TIA Eric -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [PATCH]apache_register_shutdown_function final version
At 01:37 07/01/2003, Joseph Tate wrote: Well, according to my highly technical methods of deduction (fprintf(stderr, Inside sapi_shutdown);) sapi_shutdown is never called when serving a PHP request when served using mod4_php under Apache. This is because the shutdown_wrapper never gets initialized as a cleanup function. This because the php_init_handler is never called, and this happens for some reason undivinable by me. Perhaps it should be used, and we should execute regular shutdown functions there, and proceed to use php_request_shutdown in the way it was used prior to php 4.1.x i.e. after the connection has closed (on apache anyway) and while PHP is still in memory. We'll get the added benefit of (on Apache systems anyway) a significant performance gain as the cleanup phase happens without the client having to wait for it. You must have messed up on your analysis, as php_init_handler() is certainly being called, and so is sapi_shutdown(). Place an abort() in them, it won't take more than a couple of minutes to know that for certain :) I would guess that the source of the problem is that sapi_shutdown() is simply not the function you're looking for. You're probably looking for sapi_deactivate(). Here is my vision based on my understanding of the inner workings of PHP. There are at least four types of shutdown functions in PHP (not including extensions): PHP space (identified by the use of register_shutdown_function) module_shutdown (called when a module is to clean up after itself) sapi_shutdown (not used under many sapi implementations) php_shutdown there may also be zend and tsrm shutdown functions. Not quite. First off, if we're talking about register_shutdown_function(), then we're dealing with activate/deactivate functions, and not startup/shutdown functions. In the old terms, still used by modules, we're dealing with RINIT/RSHTDOWN (request-init, request-shutdown). Activate (rinit) / deactivate (rshutdown) functions get called in the beginning and end of each request, respectively. In that regard, there are *plenty* of them. Activate/deactivate functions are called for the engine, SAPI, output buffering, whatnot. The engine, in turn, calls the activate/deactivate callbacks that are available in modules, if available. One of the deactivate actions in php_request_shutdown is to call the userland-registered shutdown functions. SAPI is just one of the many subsystems which are initialized/destroyed by php_requset_startup() and php_request_shutdown(). There's nothing special about it. php_shutdown seems to always be a call to shutdown wheras the remainder are called when shutdown occurs. Didn't quite understand that..? Thus the cleanup/shutdown routines should be called in this order: main init load and run PHP script call sapi_shutdown which calls module_shutdown on all used modules and then executes register_shutdown_functions and then calls php_request_shutdown in a server specific manner (in apache as a cleanup_function after the http communication has terminated) which (under platforms that support it) executes register_offline_functions before cleaning up PHP and freeing memory. There are many problematic things about this layout. Suffice to say that intimately knowing the shutdown order in PHP, I don't think there are any conceptual problems with it. Again, there's nothing inherent in SAPI that makes it the function of choice to be the root of all deactivation calls, as it is just one of the many subsystems in PHP. PHP's main deactivation function is php_request_shutdown(), and it calls sapi_deactivate(), because it's one of the subsystems that requires deactivation. It's the responsibility of the SAPI module to figure out the best way to ensure that php_request_shutdown() gets called at the end of each request. SAPI was developed for abstracting the server, but it seems that instead it has been worked around rather than extended for the individual servers. I speak in generalizations, but that's what it looks like. In my book, all php internal functions should be called through the appropriate SAPI functions, which are called by a main function for each sapi implementation. There is too much deviation from this, thereby crippling SAPI. Either use it or cut it out completly. These changes are too large for a minor version release, i.e. 4.3.1, but perhaps for 4.4/5.0? I'd be willing to put some time into reworking the SAPI system. I think that these harsh thoughts are mostly due to the problems in the initial analysis. SAPI is really working very very well as it is :) Zeev -- 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/mysqli mysqli_api.c
Edin Kadribasic wrote: edink Thu Feb 13 12:15:22 2003 EDT Modified files: /php4/ext/mysqli mysqli_api.c Log: Use my_ulonglong instead of unsigned long long to make msvc++ happy. Did you somehow manage to build MySQL 4.1 on Windows? If so, how? If not, how are you building ext/mysqli since it requires libmysql 4.1? -- 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] Re: [PHP-CVS] cvs: php4 /ext/mysqli mysqli_api.c
On Thu, 13 Feb 2003, Sebastian Bergmann wrote: Edin Kadribasic wrote: edink Thu Feb 13 12:15:22 2003 EDT Modified files: /php4/ext/mysqlimysqli_api.c Log: Use my_ulonglong instead of unsigned long long to make msvc++ happy. Did you somehow manage to build MySQL 4.1 on Windows? If so, how? If not, how are you building ext/mysqli since it requires libmysql 4.1? I have indeed. Lots of tweaking of project files, but I'm able to compile and load php_mysqli.dll extension and to make it show up in phpinfo(). I didn't test it beyond that. The compiled lib and header files are available at: http://snaps.php.net/~edink/libmysql-4.1.zip and the compiled extension is at http://snaps.php.net/~edink/php_mysqli.dll. Please note that I exported only symbols needed for ext/mysqli at this point so I might need to recompile it if the extension gets extended and starts using some more of the mysqli API. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/mysqli mysqli_api.c
Edin Kadribasic wrote: I have indeed. I'm trying to build the current MySQL 4.1 sources from the BitKeeper repository with MS VisualC++ 6 (VisualStudio 98, Service Pack 5) on my Windows 2000 Professional box. The prepare script produces the errors shown in http://www.sebastian-bergmann.de/prepare.txt Since my setup of MS VisualC++ 6 seems not tp be able to compile symlinked files (for whatever reason), I changed the ln -s calls in the prepare script to mv. I still get similar errors from the prepare script, but now the compiler finds the files and the build looks okay until it yields the following compiler errors: E:\home\mysql-4.1\VC++Files\strings\strto.c(98): error C2232: '-ctype': The left operand is of type 'struct', use '.' E:\home\mysql-4.1\VC++Files\strings\strto.c(118): error C2232: '-to_upper': The left operand is of type 'struct', use '.' E:\home\mysql-4.1\VC++Files\strings\strto.c(126): error C2232: '-to_upper': The left operand is of type 'struct', use '.' E:\home\mysql-4.1\VC++Files\strings\strto.c(148): error C2232: '-ctype': The left operand is of type 'struct', use '.' E:\home\mysql-4.1\VC++Files\strings\strto.c(150): error C2232: '-ctype': The left operand is of type 'struct', use '.' E:\home\mysql-4.1\VC++Files\strings\strto.c(151): error C2232: '-to_upper': The left operand is of type 'struct', use '.' -- 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] Re: [PHP-CVS] cvs: php4 /ext/mysqli mysqli_api.c
On Thursday 13 February 2003 18:32, Sebastian Bergmann wrote: Sebastian, Edink: could you please report the bugs you detected when compiling MySQL 4.1 under Windows to http://bugs.mysql.com too?! (You need to sign for a webaccount to report bugs) Georg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] solaris getcwd() brokeness
Here's that same patch, but without leaking a file
descriptor. Any comments yet? Any objections to
committing it?
-James
On Wed, 12 Feb 2003, James E. Flemer wrote:
Well all the fancy new streams code in 4.3.0 seems to
tickle a Solaris issue with getcwd(). It seems that under
certain cases solaris' getcwd() fails when other os' work.
Consequently 4.3.0 causes a huge ammount of breakage for
some sites running solaris. Below is a patch that seems to
work around the problem. This may not be the best
approach, but it was an attempt at a quick-fix so that
4.3.0 would be usable for now. This problem has bug
number: #21310 [1]. Comments welcome. I'd like to commit
this (or similar) before any more releases are made.
-James [EMAIL PROTECTED]
[1] http://bugs.php.net/21310
]] Patch sponsored by: The University of Vermont [[
-- old patch removed, new patch follows --
Index: TSRM/tsrm_virtual_cwd.c
===
RCS file: /repository/TSRM/tsrm_virtual_cwd.c,v
retrieving revision 1.41
diff -u -b -r1.41 tsrm_virtual_cwd.c
--- TSRM/tsrm_virtual_cwd.c 6 Nov 2002 18:07:22 - 1.41
+++ TSRM/tsrm_virtual_cwd.c 13 Feb 2003 20:40:07 -
@@ -303,7 +303,7 @@
return (0);
#if !defined(TSRM_WIN32) !defined(NETWARE)
- if (IS_ABSOLUTE_PATH(path, path_length)) {
+ if (IS_ABSOLUTE_PATH(path, path_length) || (state-cwd_length 1)) {
if (use_realpath realpath(path, resolved_path)) {
path = resolved_path;
path_length = strlen(path);
@@ -363,6 +363,7 @@
}
+ if (state-cwd_length 0 || IS_ABSOLUTE_PATH(path, path_length)) {
ptr = tsrm_strtok_r(path_copy, TOKENIZER_STRING, tok);
while (ptr) {
ptr_length = strlen(ptr);
@@ -416,6 +417,11 @@
state-cwd[state-cwd_length+1] = '\0';
state-cwd_length++;
}
+ } else {
+ state-cwd = (char *) realloc(state-cwd, path_length+1);
+ memcpy(state-cwd, path, path_length+1);
+ state-cwd_length = path_length;
+ }
if (verify_path verify_path(state)) {
CWD_STATE_FREE(state);
Index: main/main.c
===
RCS file: /repository/php4/main/main.c,v
retrieving revision 1.512.2.5
diff -u -b -r1.512.2.5 main.c
--- main/main.c 16 Dec 2002 15:44:06 - 1.512.2.5
+++ main/main.c 13 Feb 2003 20:40:07 -
@@ -1507,7 +1507,11 @@
{
zend_file_handle *prepend_file_p, *append_file_p;
zend_file_handle prepend_file, append_file;
+#ifdef VIRTUAL_DIR
char *old_cwd;
+#else
+ int old_cwd_fd;
+#endif
char *old_primary_file_path = NULL;
int retval = 0;
@@ -1515,9 +1519,11 @@
if (php_handle_special_queries(TSRMLS_C)) {
return 0;
}
+#ifdef VIRTUAL_DIR
#define OLD_CWD_SIZE 4096
old_cwd = do_alloca(OLD_CWD_SIZE);
old_cwd[0] = '\0';
+#endif
zend_try {
#ifdef PHP_WIN32
@@ -1528,7 +1534,11 @@
if (primary_file-type == ZEND_HANDLE_FILENAME
primary_file-filename) {
+#ifdef VIRTUAL_DIR
VCWD_GETCWD(old_cwd, OLD_CWD_SIZE-1);
+#else
+ old_cwd_fd = open(., 0);
+#endif
VCWD_CHDIR_FILE(primary_file-filename);
}
@@ -1578,10 +1588,15 @@
} zend_end_try();
+#ifdef VIRTUAL_DIR
if (old_cwd[0] != '\0') {
VCWD_CHDIR(old_cwd);
}
free_alloca(old_cwd);
+#else
+ fchdir(old_cwd_fd);
+ close(old_cwd_fd);
+#endif
return retval;
}
/* }}} */
Index: main/safe_mode.c
===
RCS file: /repository/php4/main/safe_mode.c,v
retrieving revision 1.51
diff -u -b -r1.51 safe_mode.c
--- main/safe_mode.c6 Nov 2002 18:07:23 - 1.51
+++ main/safe_mode.c13 Feb 2003 20:40:07 -
@@ -121,6 +121,8 @@
VCWD_REALPATH(filename, path);
*s = DEFAULT_SLASH;
} else {
+ path[0] = '.';
+ path[1] = '\0';
VCWD_GETCWD(path, sizeof(path));
}
} /* end CHECKUID_ALLOW_ONLY_DIR */
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] build no longer working
I updated all m4,autoconf libtool AND now i can no longer build php Anybody help? using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.54 (ok) buildconf: Your version of autoconf likely contains buggy cache code. Running cvsclean for you. To avoid this, install autoconf-2.13 and automake-1.5. buildconf: automake version 1.5 (ok) buildconf: libtool version 1.4.3 (ok) rebuilding configure configure.in:830: warning: AC_PROG_LIBTOOL is m4_require'd but is not m4_defun'd configure.in:143: error: possibly undefined macro: AC_MSG_RESULT If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.in:292: error: possibly undefined macro: AC_DEFINE configure.in:1064: error: possibly undefined macro: AC_PROG_LIBTOOL configure:95991: error: possibly undefined macro: _LT_AC_TRY_DLOPEN_SELF rebuilding acconfig.h rebuilding main/php_config.h.in WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' WARNING: and `config.h.top', to define templates for `config.h.in' WARNING: is deprecated and discouraged. WARNING: Using the third argument of `AC_DEFINE' and WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without WARNING: `acconfig.h': WARNING: AC_DEFINE([NEED_MAIN], 1, WARNING: [Define if a function `main' is needed.]) WARNING: More sophisticated templates can also be produced, see the WARNING: documentation. configure.in:830: warning: AC_PROG_LIBTOOL is m4_require'd but is not m4_defun'd -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] build no longer working
On Thu, 13 Feb 2003 23:29:44 +0100 [EMAIL PROTECTED] (Marcus Börger) wrote: I updated all m4,autoconf libtool AND now i can no longer build php Anybody help? using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.54 (ok) Did you try with autoconf 2.13 ? / Magnus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] build no longer working
On Thu, 13 Feb 2003, Marcus Börger wrote: I updated all m4,autoconf libtool AND now i can no longer build php Anybody help? Get autoconf-2.13 and m4-1.4 (not 1.4o) from ftp.gnu.org. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Weird PHP5 APXS libtools errors
On Thu, 2003-02-13 at 09:52, John Coggeshall wrote: From HEAD: [...] libtool: s%^.*/%%: No such file or directory libtool: -e: command not found libtool: -e: command not found libtool: -e: command not found libtool: -e: command not found libtool: -e: command not found (more of these) Try $ SED=sed ./configure ... or $ export SED=sed $ ./configure ... Somehow, the variable SED is not set. - Timm -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Weird PHP5 APXS libtools errors
$ export SED=sed $ ./configure ... Somehow, the variable SED is not set. I was just looking at the MakeFile trying to figure this out and I was thinking it must be something like that. It works now -- thanks... But why would SED suddenly stop being defined? Did I break something unintentially (meaning SED should always be defined?) or is PHP failing to define it for some reason? John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] build no longer working
At 01:57 14.02.2003, Jani Taskinen wrote: On Fri, 14 Feb 2003, Marcus Börger wrote: AC_PROG_LIBTOOL is defined in libtool.m4, which should come from libtool installation. Most likely you've just got mixed up versions in your system. Easiest way to get it working is to remove _all_ the auto* tools and libtool. And compile all from sources. With same prefix.. --Jani Is it possible that i have a problem due to the order of build and install? marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] build no longer working
On Fri, 14 Feb 2003, Marcus Börger wrote: At 01:57 14.02.2003, Jani Taskinen wrote: On Fri, 14 Feb 2003, Marcus Börger wrote: AC_PROG_LIBTOOL is defined in libtool.m4, which should come from libtool installation. Most likely you've just got mixed up versions in your system. Easiest way to get it working is to remove _all_ the auto* tools and libtool. And compile all from sources. With same prefix.. --Jani Is it possible that i have a problem due to the order of build and install? Ensure that m4 --version actually outputs 1.4 and not 1.4o. Some rpms are mislabeled in that area. Otherwise, the only problem source comes from having a polluted installation where multiple autoconf/libtool versions are sprinkled through the whole system. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] List of all functions
I would very much like a complete list of all functions in PHP 4.3.0. Is there a way to generate this from the source tree or do I have to go through it all by hand? -- Rickard -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] List of all functions
On Fri, 14 Feb 2003, Rickard Andersson wrote: I would very much like a complete list of all functions in PHP 4.3.0. Is there a way to generate this from the source tree or do I have to go through it all by hand? Try http://www.zugeschaut-und-mitgebaut.de/php/ There are also some awk scripts around which extract that information. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: List of all functions
I'm such an idiot! 20 seconds after I posted I found this: http://www.php.net/quickref.php I'm really sorry :-) -- Rickard -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/mysqli mysqli_api.c
Georg Richter wrote: could you please report the bugs you detected when compiling MySQL 4.1 under Windows to http://bugs.mysql.com too?! I'm in contact now with the MySQL team's Windows guy. -- 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: Apache 2.x / PHP 4.2.3 compatibility issue
On your apache2 compatibility page you state Apache 2.0 SAPI-support started with PHP 4.2.0. PHP 4.2.3 its known to work in conjunction with Apache 2.0.39. Don't try to use this version of PHP with any other version of Apache. We do not recommend to use PHP 4.2.3 along with Apache 2.0.39. This is totally confusing. PHP 4.2.3 its known to work with Apache 2.0.39 (besides being grammatically incorrect) does not agree with We do not recommend using PHP4.2.3 along with Apache 2.0.39. Do they work allright togethe,rbut you just personally do not recommend the combination? They won't work togerther in some cases. That information was provided by the server API developers, who probably know what are the problems, but this is a user documentation, so we have not detailed, what is the problem exactly... BTW that grammar problem should be fixed, yes... Goba [one [EMAIL PROTECTED]] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: function.main
Gabor Hojtsy wrote: If you turn of html_errors, that should turn off that link too IMHO, not tested though... well, what if i want html errors in the html output but not in the error_log (where they dont make sense) ? ;) -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 Sie finden uns auf der CeBIT in Halle 6/H44 http://www.six.de/cebit2003/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
