[PHP-DEV] New config.m4 for ext/xmlrpc

[Brian France]

I tried to build xmlrpc as a shared extension (phpize, ./configure, 
make), but when it builds it didn't have dependences for libexpat and 
libiconv, but the expat, libiconv and XMLRPC_ functions are undefined.

While trying to fix this I rewrote the config.m4 to handle all the 
following build cases:

1)  built-in to PHP with libxmlrpc included from extension directory
 --with-xmlrpc

2)  built-in to PHP with shared libxmlrpc
 --with-xmlrpc --with-libxmlrpc=/usr/local

3)  built shared with libxmlrpc included from extension directory
 --with-xmlrpc=shared

4)  built shared with shared libxmlrpc
 --with-xmlrpc=shared --with-libxmlrpc=/usr/local


There is one part I don't like and that is the new option of 
--with-libxmlrpc is only used in a state where it is not equal to 
'yes' or 'no'.  It would have a directory value, but I don't like how 
it I did it.

Is this the best way to handle it?  Comments? Should I open a bug and 
submit this?

For the new config.m4 to work, xmlrpc-epi-php.c needs this changed:

#ifndef PHP_WIN32
#include "php_config.h"
#endif

to:

#ifdef HAVE_CONFIG_H
#include "config.h"
#endif

Also what does PHP_FAST_OUTPUT do?

Thanks,

Brian

--

sinclude(ext/xmlrpc/libxmlrpc/acinclude.m4)
sinclude(ext/xmlrpc/libxmlrpc/xmlrpc.m4)
sinclude(libxmlrpc/acinclude.m4)
sinclude(libxmlrpc/xmlrpc.m4)

PHP_ARG_WITH(xmlrpc, for XMLRPC-EPI support,
[  --with-xmlrpc Include XMLRPC-EPI support.])

PHP_ARG_WITH(libxmlrpc, Use shared libxmlrpc for XMLRPC-EPI,
[  --with-libxmlrpc[=DIR]   Will build and include the local copy of 
XMLRPC-EPI,
 unless the DIR is set. ])

PHP_ARG_WITH(expat-dir, libexpat dir for XMLRPC-EPI,
[  --with-expat-dir=DIR  XMLRPC-EPI: libexpat dir for XMLRPC-EPI.])


if test "$PHP_XMLRPC" != "no"; then

 PHP_EXTENSION(xmlrpc, $ext_shared)
 PHP_SUBST(XMLRPC_SHARED_LIBADD)

 if test "$PHP_LIBXMLRPC" = "no" || test "$PHP_LIBXMLRPC" = "yes"; then
 XMLRPC_CHECKS
 XMLRPC_SHARED_LIBADD=libxmlrpc/libxmlrpc.la
 XMLRPC_LIBADD=libxmlrpc/libxmlrpc.la
 XMLRPC_SUBDIRS=libxmlrpc
 PHP_SUBST(XMLRPC_LIBADD)
 PHP_SUBST(XMLRPC_SUBDIRS)
 AC_DEFINE(HAVE_BUNDLED_XMLRPC, 1, [ ])
 dnl  PHP_FAST_OUTPUT($ext_builddir/libxmlrpc/Makefile)
 LIB_BUILD($ext_builddir/libxmlrpc,$ext_shared,yes)

 PHP_ADD_INCLUDE($ext_srcdir/libxmlrpc)
 else
 if test -r $PHP_XMLRPC/include/xmlrpc.h; then
   XMLRPC_DIR=$PHP_XMLRPC
 else
   AC_MSG_CHECKING([for XMLRPC-EPI in default path])
   for i in /usr/local /usr; do
 if test -r $i/include/xmlrpc.h; then
   XMLRPC_DIR=$i
   AC_MSG_RESULT(found in $i)
 fi
   done
 fi

 if test -z "$XMLRPC_DIR"; then
   AC_MSG_ERROR([XMLRPC-EPI not found, please reinstall the 
XMLRPC-EPI distribution])
 fi

 PHP_ADD_INCLUDE($XMLRPC_DIR/include)
 PHP_ADD_LIBRARY_WITH_PATH(xmlrpc, $XMLRPC_DIR/lib, 
XMLRPC_SHARED_LIBADD)
 fi

 PHP_SUBST(EXPAT_SHARED_LIBADD)
 AC_DEFINE(HAVE_LIBEXPAT,  1, [ ])

 for i in $PHP_XML $PHP_EXPAT_DIR; do
   if test -f $i/lib/libexpat.a -o -f 
$i/lib/libexpat.$SHLIB_SUFFIX_NAME ; then
 EXPAT_DIR=$i
   fi
 done

 if test -z "$EXPAT_DIR"; then
   AC_MSG_ERROR(not found. Please reinstall the expat distribution.)
 fi

 PHP_ADD_INCLUDE($EXPAT_DIR/include)
 PHP_ADD_LIBRARY_WITH_PATH(expat, $EXPAT_DIR/lib, XMLRPC_SHARED_LIBADD)

 if test "$PHP_ICONV" = "no"; then
   PHP_ICONV=yes
 fi

 PHP_SETUP_ICONV(XMLRPC_SHARED_LIBADD, [], [
   AC_MSG_ERROR([iconv not found, in order to build xmlrpc you 
need the iconv library])
 ])

 AC_DEFINE(HAVE_XMLRPC, 1, [ ])
fi

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring

[Brian France]

At 10:49 AM +0100 9/1/02, James Cox wrote:
>I vote to remove mbstring as a default module.

I completely agree!

I do have one request, when the time comes to remove it from the 
default also change the PHP core code so that it can be built as a 
shared extension and loaded on the fly.  Currently it can only be 
compiled into PHP statically and building it as .so means hacking the 
PHP source and the mbstring module (which I have already done with a 
small patch).

Just my 2 cents.

Thanks,

Brian

BTW, sorry if this has been already done in the CVS tree and I didn't catch it.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] mbstring

[Brian France]

At 6:29 PM +0100 9/1/02, James Cox wrote:
>Where is your patch?

The patch basically renames php_treat_data to php_treat_data_default,
creates a function pointer called php_treat_data that is defaulted to
php_treat_data_default, removes all mbstrings references in php_main.h
and makes mbstring.c change the php_treat_data to mbstr_treat_data in
the INIT function and restores its value in SHUTDOWN.

This allows us to only load the mbstrings extension on the machines 
that need it, which is a very small percentage of our over all server 
count.

This patch is based off of the 4.2.2 release and there have been 
changes in CVS to the exif extension that may need mbstring to be 
static because it is expecting mbstr_treat_data to be handling the 
php_treat_data stuff.

There was also talk about moving the changing mbstr_treat_data to be 
the default handler since there was so much duplicate code in 
mbstring.

Thanks,

Brian

--

diff -rc php-4.2.2/ext/mbstring/mbstring.c php-4.2.2/ext/mbstring/mbstring.c
*** php-4.2.2/ext/mbstring/mbstring.c   Wed Apr 24 02:46:23 2002
--- php-4.2.2/ext/mbstring/mbstring.c   Mon Jun 10 14:10:58 2002
***
*** 93,98 
--- 93,100 
{ MULTIPART_CONTENT_TYPE, 
sizeof(MULTIPART_CONTENT_TYPE)-1,   NULL, 
rfc1867_post_handler },
{ NULL, 0, NULL, NULL }
   };
+
+ void mbstr_treat_data(int arg, char *str, zval* destArray TSRMLS_DC);
   #endif

   static struct mb_overload_def mb_ovld[] = {
***
*** 529,534 
--- 531,538 
   #if defined(MBSTR_ENC_TRANS)
sapi_unregister_post_entry(mbstr_post_entries);
sapi_register_post_entries(mbstr_post_entries);
+
+ php_treat_data = mbstr_treat_data;
   #endif

REGISTER_LONG_CONSTANT("MB_OVERLOAD_MAIL", MB_OVERLOAD_MAIL, 
CONST_CS | CONST_PERSISTENT);
***
*** 552,557 
--- 556,565 

   #if HAVE_MBREGEX
zend_hash_destroy(&MBSTRG(ht_rc));
+ #endif
+
+ #if defined(MBSTR_ENC_TRANS)
+ php_treat_data = php_treat_data_default;
   #endif

return SUCCESS;
diff -rc php-4.2.2/main/php_main.h php-4.2.2/main/php_main.h
*** php-4.2.2/main/php_main.h   Mon Mar  4 10:46:55 2002
--- php-4.2.2/main/php_main.h   Mon Jun 10 14:09:59 2002
***
*** 53,60 
   extern int php_init_environ(void);
   extern int php_shutdown_environ(void);

- #if defined(MBSTR_ENC_TRANS)
- #define php_treat_data mbstr_treat_data
- #endif
-
   #endif
--- 53,56 
diff -rc php-4.2.2/main/php_variables.c php-4.2.2/main/php_variables.c
*** php-4.2.2/main/php_variables.c  Tue Dec 11 07:31:05 2001
--- php-4.2.2/main/php_variables.c  Mon Jun 10 14:09:59 2002
***
*** 28,33 
--- 28,34 

   #include "zend_globals.h"

+ void *(*php_treat_data)(int arg, char *str, zval* destArray 
TSRMLS_DC) = php_treat_data_default;

   PHPAPI void php_register_variable(char *var, char *strval, zval 
*track_vars_array TSRMLS_DC)
   {
***
*** 215,221 
   }


! void php_treat_data(int arg, char *str, zval* destArray TSRMLS_DC)
   {
char *res = NULL, *var, *val, *separator=NULL;
const char *c_var;
--- 216,222 
   }


! void php_treat_data_default(int arg, char *str, zval* destArray TSRMLS_DC)
   {
char *res = NULL, *var, *val, *separator=NULL;
const char *c_var;
diff -rc php-4.2.2/main/php_variables.h php-4.2.2/main/php_variables.h
*** php-4.2.2/main/php_variables.h  Tue Dec 11 07:31:05 2001
--- php-4.2.2/main/php_variables.h  Mon Jun 10 14:09:59 2002
***
*** 30,36 
   #define PARSE_COOKIE 2
   #define PARSE_STRING 3

! void php_treat_data(int arg, char *str, zval* destArray TSRMLS_DC);
   PHPAPI void php_import_environment_variables(zval *array_ptr TSRMLS_DC);
   PHPAPI void php_register_variable(char *var, char *val, pval 
*track_vars_array TSRMLS_DC);
   /* binary-safe version */
--- 30,39 
   #define PARSE_COOKIE 2
   #define PARSE_STRING 3

! extern void *(*php_treat_data)(int arg, char *str, zval* destArray 
TSRMLS_DC);
!
! void php_treat_data_default(int arg, char *str, zval* destArray TSRMLS_DC);
!
   PHPAPI void php_import_environment_variables(zval *array_ptr TSRMLS_DC);
   PHPAPI void php_register_variable(char *var, char *val, pval 
*track_vars_array TSRMLS_DC);
   /* binary-safe version */

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] mbstring

[Brian France]

At 8:47 PM +0200 9/1/02, Marcus Börger wrote:
>At 20:38 01.09.2002, Brian France wrote:
>>At 6:29 PM +0100 9/1/02, James Cox wrote:
>>>Where is your patch?
>>
>>The patch basically renames php_treat_data to php_treat_data_default,
>>creates a function pointer called php_treat_data that is defaulted to
>>php_treat_data_default, removes all mbstrings references in php_main.h
>>and makes mbstring.c change the php_treat_data to mbstr_treat_data in
>>the INIT function and restores its value in SHUTDOWN.
>>
>>This allows us to only load the mbstrings extension on the machines
>>that need it, which is a very small percentage of our over all
>>server count.
>>
>>This patch is based off of the 4.2.2 release and there have been
>>changes in CVS to the exif extension that may need mbstring to be
>>static because it is expecting mbstr_treat_data to be handling the
>>php_treat_data stuff.
>
>exif uses mbstring since 4.3 so 4.2.3 would be no problem

Which means that my fix would fix it for 4.2.x releases and then it
breaks again in 4.3. Break, I mean mbstring can not be built as a
shared extension.

I know there are things the exif needs from mbstring and there is no
way to have exif link against mbstring or require it.  But couldn't
exif check to see if mbstring is loaded (or built in) and if not
print a warning that some of its functionality may not work correctly
unless mbstring is loaded (or built in)?

Thanks,

Brian

--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring

[Brian France]

I know this is ugly, but what about making the extensions handle it themselves?

Your example of session_pgsql:

In the extension init code:

ext_enabled = 1;

if ( dlsym( NULL, "psql_module_entry" ) == NULL &&
  dlsym( NULL, "_psql_module_entry" ) == NULL )
{
 // print some warning about needing the pgsql extension
 // or pgsql should be loaded before this one in the php.ini
 ext_enabled = 0;
}

if ( dlsym( NULL, "session_module_entry" ) == NULL &&
  dlsym( NULL, "_session_module_entry" ) == NULL )
{
 // print some warning about needing the session extension
 // or session should be loaded before this one in the php.ini
 ext_enabled = 0;
}

The second call with a underscore is to handle Openbsd and old 
version of FreeBSD, I think a.out things.  I am sure this can be 
handled differently, but you get the point.

Cheers,

Brian

At 9:19 AM +0900 9/2/02, Yasuo Ohgaki wrote:
>We know current module loader is not smart :)
>
>As number of modules increases, number of module depends on another 
>increases. Examples are mbstirng/mailparse/exif, 
>session/msession/session_pgsql and bunch of session save handler
>modules out there, session_pgsql depends of session and pgsql module,
>etc.
>
>(Loading sessoin save handler as module does not work at all, since
>current module loader isn't take into module dependency at all)
>
>I would like to see smart module loader and/or ini parser that can
>address this issue. PHP crashes easily w/o it.
>
>IF statemnet is better than now, but it's not good enough.
>I don't think this carefully, but here is my idea.
>
>Add following member so that get_module() retrive
>  loading weight (we need this so that we can control sub module
>  loading order)
>  list modules depend on
>Check if module required is there, raise E_WARNING
>  if module cannot be loaded.
>Sort modules so that modules are loaded w/o problem.
>Load modules.
>
>This is easy to implement, isn't it?
>We may better to have smart ini parser, but it may not be
>required strictly for this purpose.
>
>I don't have plan to write this, since I need to modify
>engine code. I hope Andi or Zeev like this idea for PHP5 :)
>
>BTW, I'm +1 for having IF statement in php.ini.
>
>--
>Yasuo Ohgaki


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring

[Brian France]

At 9:25 AM +0900 9/2/02, Yasuo Ohgaki wrote:
>As all of us know, PHP crashes easily when module is loaded
>improperly.

Has anybody tracked down why this is?

This could have been the problem, but is fixed now:

http://bugs.php.net/?id=17643

(I think this link is right, bugs is down right now)

Brian





-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Default extensions (extensions in general)

[Brian France]

Personally I don't care what is the default extensions are as long as 
I can change them.

(I have written this email several times, but never sent it or I may 
have, but don't remember if so sorry if repeating).

Here are my problems with extensions:

A) Extensions that change the core code when built statically.

I think this should not be possible! 4.3 takes care of this problem 
with mbstring and I don't know of any others, but that doesn't mean 
it can't happen again.

B) Extensions that can only be built statically or while PHP is building.

   4.3 version of sessions fixes this (I think), but you can't build 
session shared with
 out mm in version 4.2.x (via phpize)

   Any/All extension should have to pass a test of:

   1) Can it be built and work statically into PHP
   2) Can it be built shared while building PHP
   3) Can it be built shared by phpize, configure, make method.

   Also can I do steps 1-3 with any of its options enabled or disabled

   If it includes extra sources (xml -> expat, xmlrpc -> libxmlrpc)

   1) Can it be built statically into PHP with included library
   2) Can it be built statically into PHP with a shared library
   3) Can it be built with PHP shared with included library
   4) Can it be built with PHP shared with a shared library
   5) Can it be built shared by phpize, configure, make method with 
included library.
   6) Can it be built shared by phpize, configure, make method a shared library.

   Also can I do steps 1-6 with any of its options enabled or disabled

   Also, just because they configure and build a .so files doesn't 
mean they work and have the right dependences.  That should be tested 
as well.

   If all these things are meet then somebody can build a bare bones 
PHP and build extensions as needed.  Currently not all extension can 
do this.

   It would be nice to make the above a requirement to get into the 
ext directory and recommended for things in pear/pecl.

That's just my opinion, I could be wrong.

Brian

BTW, Thanks to Jani Taskinen for putting up with me while fixing a 
few extensions.


At 10:19 PM +0100 9/2/02, James Cox wrote:
>  > Unfortunately we don't live in a perfect world where
>>  sysadmins know how to read and listen to their users
>>  requests. That's why mysql for example is enabled by default.
>>  (or that's the main reasoning behind it at least)
>>
>>  And we can't educate people or force them to anything either.
>>
>>  Maybe we should add a general '--disable-all' option?
>>
>
>i'm +1 for that if it means that first it disables everything, and then you
>enable stuff bit by bit...
>
>i still don't see why we shouldn't just disable everything by default and
>write a 'default configure' script...
>
>  -- james
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [TEST] Delete me!

[Brian France]

This is just a ping test to see if my co-location company got off of 
the spews.org black list.

Brian

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] php.ini include directive

[Brian France]

Has anybody looked into doing a include directive for the php.ini file?

Something like what Apache has?

http://httpd.apache.org/docs/mod/core.html#include

Thoughts?

Cheers,

Brian

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php.ini include directive

[Brian France]

I don't think we are talking about the same thing.

I would like to do something like this:

php.ini
---
[PHP]

include = php-mbstring.ini
---

php-mbstring.ini
---
[mbstring]
mbstring.internal_encoding = EUC-JP
mbstring.http_input = auto
mbstring.http_output = EUC-JP
mbstring.detect_order = auto
mbstring.substitute_character = none;
---

or this would include all .ini files from the include directory

php.ini
---
[PHP]

include = include/
---


Or may be a something like this:

php.ini
---
[PHP]


[INCLUDE]
file = php-mbstring.ini
file = php-mysql.ini
directory = include/
---

Brian


At 1:59 PM -0400 9/11/02, [EMAIL PROTECTED] wrote:
>I see how this could be useful, possibly for custom session handlers or
>including something at the top of every file for free hosted customers or
>something (so that they can't get around the ads or whatever).
>
>Anyway, I don't know.  I give this maybe +.25 for right now, see what
>reactions are.
>
>I could put together a quick patch for this if people thought it would be
>useful.  If you guys like the idea, lemme know, and I'll patch it.
>
>Devon
>
>Original Message:
>-
>From: Brian France [EMAIL PROTECTED]
>Date: Wed, 11 Sep 2002 10:56:06 -0700
>To: [EMAIL PROTECTED]
>Subject: [PHP-DEV] php.ini include directive
>
>
>Has anybody looked into doing a include directive for the php.ini file?
>
>Something like what Apache has?
>
>http://httpd.apache.org/docs/mod/core.html#include
>
>Thoughts?
>
>Cheers,
>
>Brian
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
>mail2web - Check your email from the web at
>http://mail2web.com/ .
>
>
>
>--
>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] [RFC] include_ini and include_ini_dir

[Brian France]

I have created a patch for two new .ini directives:

include_ini =  ; relative  or full path
include_ini_dir = 

The patch is only in php_ini.c and does the following:

Added 2 new static zend_llist: include_ini_list & include_ini_dir_list

Add a case for include_ini and include_ini_dir in function 
php_config_ini_parser_cb.
This new cases just add items to the static lists.

Added three new functions:

php_include_ini_load
   - Loads a .ini file from a passed in name (may be full path)

php_include_ini_function_cb
   - callback loop over include_ini_list, which calls php_include_ini_load

php_include_ini_dir_function_cb
   - callback loop over include_ini_dir_list, which calls 
php_include_ini_load on each file in a directory.

In function php_init_config the new llist are init'ed and after 
zend_parse_ini_file is called, a loop is started until both 
include_ini_list and include_ini_dir_list are empty:

   loop over each item in include_ini_list calling php_include_ini_function_cb
   empting include_ini_list

   loop over each item in include_ini_dir_list calling 
php_include_ini_dir_function_cb
   empting include_ini_dir_list

I am assumming that in the middle of a zend_llist_apply call if 
something is added to the llist,  that item get the function applied 
to it? Right?

Problems:
   I don't know how well this will work on Windows machines.

   The new php_include_ini_load is a hacked version of php_init_config 
and doesn't rely on paths from the commend line for searching.  I 
would like some help to fix up this functions.

   include_ini_dir has to be the full path.  I didn't know the best 
way to find the directory from the search path like how the 
php_fopen_with_path does it (so I just make it work with full paths). 
Please tell me how to do this so I can use the search paths and 
relative directories names.

   Yes, it is based off of the 4.2.3 release, but I am looking for 
more input on fixing current problems then getting into the next 
release.

Cheers,

Brian



--- php-4.2.3.org/main/php_ini.cMon Mar  4 16:21:28 2002
+++ php-4.2.3/main/php_ini.cWed Sep 11 17:10:42 2002
@@ -41,6 +41,8 @@
  static HashTable configuration_hash;
  PHPAPI char *php_ini_opened_path=NULL;
  static php_extension_lists extension_lists;
+static zend_llist include_ini_list;
+static zend_llist include_ini_dir_list;

  /* {{{ php_ini_displayer_cb
   */
@@ -166,6 +168,14 @@
char *extension_name = 
estrndup(Z_STRVAL_P(arg2), Z_STRLEN_P(arg2));

 
zend_llist_add_element(&extension_lists.engine, 
&extension_name);
+   } else if 
(!strcasecmp(Z_STRVAL_P(arg1), "include_ini")) {
+   char *ini_name = 
estrndup(Z_STRVAL_P(arg2), Z_STRLEN_P(arg2));
+   zend_llist_add_element( 
&include_ini_list, &ini_name );
+   fprintf(stderr, "got 
include_ini = %s\n", Z_STRVAL_P(arg2) );
+   } else if 
(!strcasecmp(Z_STRVAL_P(arg1), "include_ini_dir")) {
+   char *ini_name = 
estrndup(Z_STRVAL_P(arg2), Z_STRLEN_P(arg2));
+   zend_llist_add_element( 
&include_ini_dir_list, &ini_name );
+   fprintf(stderr, "got 
include_ini_dir = %s\n", Z_STRVAL_P(arg2) );
} else {
 
zend_hash_update(&configuration_hash, Z_STRVAL_P(arg1), 
Z_STRLEN_P(arg1)+1, arg2, sizeof(zval), (void **) &entry);
Z_STRVAL_P(entry) = 
zend_strndup(Z_STRVAL_P(entry), Z_STRLEN_P(entry));
@@ -178,6 +188,147 @@
  }
  /* }}} */

+
+static void php_include_ini_load( char *ini_file )
+{
+   char *env_location, *php_ini_search_path;
+   int safe_mode_state;
+   char *open_basedir;
+   char *php_include_ini_opened_path = NULL;
+   int free_ini_search_path=0;
+   zend_file_handle fh;
+   TSRMLS_FETCH();
+
+   fprintf( stderr, "php_include_ini_function_cb: %s\n", ini_file );
+
+   safe_mode_state = PG(safe_mode);
+   open_basedir = PG(open_basedir);
+
+   env_location = getenv("PHPRC");
+   if (!env_location) {
+   env_location="";
+   }
+   if (0) {
+   //php_ini_search_path = php_ini_path_override;
+   //  free_ini_search_path = 0;
+   } else {
+   char *default_location;
+   int free_default_location;
+
+#ifdef PHP_WIN32
+   default_location = (char *) emalloc(512);
+
+   if (!GetWindowsDirectory(default_location, 255)) {
+   default_location[0]=0;
+   }
+   free_default_location=1;
+#else
+   default_location = PHP_CONFIG_FILE_PATH;
+   free_default_location=0;
+#endif
+   php_ini_search_path = (char *) 
emalloc(sizeof(".")+strlen(env_location)+s

[PHP-DEV] Re: [RFC] include_ini and include_ini_dir

[Brian France]

At 11:25 AM +0900 9/12/02, Yasuo Ohgaki wrote:
>How this could be useful?

I work for a company that is moving towards PHP.  We have our own 
package system for installing software, something like FreeBSD ports. 
I am the one that builds the PHP dso package.  The PHP package 
could/will be installed on tens of thousands of servers so it is bare 
bones build.  The PHP package installs a default php.ini file with 
our company defaults.  When somebody needs an extension we create 
another package of a phpize, configure, make process build of that 
extension.  When installing/removing the extension package it 
automaticly adds/removes the extension line in the php.ini and 
restarts apache.  With more and more extension, extensions that need 
more then just a one line added to the php.ini and our security team 
request it would be a lot easier to have a include_ini_dir 
(include_ini make sense, but less useful to us).

With a default php.ini file that looks like this:

-
[PHP]
include_ini_id = include
-

With this we can install 3 .ini files into the include directory for 
the base install.  One engineers can change, one engineers can change 
but should have a good reason and one that if engineers change our 
security team will beat them with a big stick.

This also helps when installing/removing extensions because we could 
just add/remove a .ini file in the include directory instead of 
editing the php.ini

Make sense?

Brian

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] include_ini and include_ini_dir

[Brian France]

Sorry that should have been:

-
[PHP]
include_ini_dir = include
-

Brian

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] include_ini and include_ini_dir

[Brian France]

At 3:09 AM +0100 9/12/02, Wez Furlong wrote:
>Arrgh! You should *really* be working against HEAD because there have
>been so many changes since we branched 4.2 - and some of those were
>related to php.ini detection.
>
>It's a LOT easier to deal with patches against HEAD (take a look in
>README.SUBMITTING_PATCH), as most of php-dev have HEAD ready-to-hack;
>not all of us have the 4.2 branch handy, and our policy is not to add
>new features to it.

Sorry, I will do a little work on this and get it ported to cvs HEAD.

Brian

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] process in README.SELF-CONTAINED-EXTENSIONS broken?

[Brian France]

I have seen the configure error before.  Don't know if this is what 
you are doing, but for me it was using phpize from 4.2.x and trying 
to build 4.3 extensions.

Hope this helps,

Brian

At 11:27 AM -0700 9/12/02, Brian Lalor wrote:
>I just grabbed PHP from CVS and tried to go through the procedure outlined in
>README.SELF-CONTAINED-EXTENSIONS and found that it doesn't work.  Can someone
>help?  I'm looking at revision 1.10 of the README.
>
>The php4 module's checked out into my ~/devel directory.  So under CONVERTING
>AN EXISTING EXTENSION, I do
> mkdir /tmp/newext
> cd /tmp/newext
> cp -rp ~/devel/php4/ext/sockets/* .
> phpize
>
>phpize gives some warnings:
> aclocal: macro `AC_ADD_LIBPATH' defined in acinclude.m4 but never used
> aclocal: macro `AC_ADD_LIBRARY' defined in acinclude.m4 but never used
> aclocal: macro `AC_ADD_LIBRARY_WITH_PATH' defined in 
>acinclude.m4 but never used
> aclocal: macro `AC_ADD_INCLUDE' defined in acinclude.m4 but never used
> You should update your `aclocal.m4' by running aclocal.
>
>I ran aclocal, which gave the same output as phpize, save for the last line;
>finally:
> ./configure
>
>configure dies with:
> configure: error: can not find sources in . or ..
>
>I've tried running buildconf and configure in the cvs working directory, but
>still no dice.  Can anyone help?
>
>B  
>
>--
>Brian Lalor
>[EMAIL PROTECTED]
>[EMAIL PROTECTED]
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Return array in parameter from extension

[Brian France]

Try this:

/*** array your_ext_func() ***/
ZEND_FUNCTION(your_ext_func)
{
zval *val_ret, *val_str;
char *output;
int ret;

output = (char *)emalloc( 100 );



array_init(return_value);
MAKE_STD_ZVAL(val_ret);
MAKE_STD_ZVAL(val_str);

ZVAL_LONG(val_ret, ret );
ZVAL_STRING(val_str, output, 0);

/*** return_value is an array, [0] is value ret, [1] is 
string output ***/
zend_hash_next_index_insert( HASH_OF(return_value), &val_ret, 
sizeof(zval *), NULL );
zend_hash_next_index_insert( HASH_OF(return_value), &val_str, 
sizeof(zval *), NULL );
}


In your php file do this:

list($ret,$str) =  your_ext_func();

Just a simple example, edit as needed.

Brian

At 6:21 PM +0200 9/24/02, Ole Stakemann wrote:
>How do I do that in an extension? I want to adhere to the 
>recommendation that allow_call_time_pass_reference should be off.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] CVS Account Request: bfrance

[Brian France]

Working with Rasmus on PHP bug fixes

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Problems with extensions...

[Brian France]

I am changing the way I build my PHP extension and am running into 
some problems. I was originally would build it by copying the 
directory foo_bar into the ext directory and added 
--enable-foo_bar=shared to the configure line of PHP and build PHP. 
Everything worked great!  Now I am looking to build it by:

phpize
./configure --enable-foo_bar=shared
make

If I build PHP with the module and install it, 
include/php/main/php_config.h would have two lines in it:

/*   */
#define HAVE_FOO_BAR 1

/* Whether to build foo_bar as dynamic module */
#define COMPILE_DL_FOO_BAR 1

And now any clean rebuilds of the extension using the phpize way will work.

Now if I do a clean build and install of PHP without the module, then 
try to build the module PHP via phpize, PHP can't load it.  Running 
nm on it reveals that the get_module function is not in the .so file. 
I have traced the missing get_module function down to:

#ifdef COMPILE_DL_FOO_BAR
ZEND_GET_MODULE(foo_bar)
#endif

and COMPILE_DL_FOO_BAR is not defined at compile time.  This is not 
defined because after running phpize config.h.in and configure are 
different:

--- config.h.in
#undef COMPILE_DL_FOO_BAR

---configure
#define COMPILE_DL_FOOBAR 1

It seems that the configure script is getting the underscore removed 
from the module name.  From what I can tell this is done in 
acinclude.m4 line 962:

AC_DEFINE_UNQUOTED([COMPILE_DL_]translit($1,a-z-,A-Z_), 1, Whether to 
build $1 as dynamic module)

I think this needs to be changed to:

AC_DEFINE_UNQUOTED([COMPILE_DL_]translit($1,a-z_-,A-Z_-), 1, Whether 
to build $1 as dynamic module)

This will handle extensions with both dashes and underscores, I think.

I also find the same line in the aclocal.m4, so it may need changed there to.

Am I off base here or is this a bug? I thought I would as before 
submitting a bug report.

Thanks,

Brian

BTW, no my extension is not named foo_bar, but it does have a underscore it.






-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Problems with extensions...

[Brian France]

After reviewing my fix for this I realize that #define labels can 
only have A-Z and underscores so this is a better fix:

From:

AC_DEFINE_UNQUOTED([COMPILE_DL_]translit($1,a-z-,A-Z_), 1, Whether to 
build $1 as dynamic module)


To:

AC_DEFINE_UNQUOTED([COMPILE_DL_]translit($1,a-z-,A-Z_), 1, Whether to 
build $1 as dynamic module)

Should I just submit a bug report on this or am I still missing something?

Thanks,

Brian

At 1:33 PM -0700 5/24/02, Brian France wrote:
>I am changing the way I build my PHP extension and am running into 
>some problems. I was originally would build it by copying the 
>directory foo_bar into the ext directory and added 
>--enable-foo_bar=shared to the configure line of PHP and build PHP. 
>Everything worked great!  Now I am looking to build it by:
>
>phpize
>./configure --enable-foo_bar=shared
>make
>
>If I build PHP with the module and install it, 
>include/php/main/php_config.h would have two lines in it:
>
>/*   */
>#define HAVE_FOO_BAR 1
>
>/* Whether to build foo_bar as dynamic module */
>#define COMPILE_DL_FOO_BAR 1
>
>And now any clean rebuilds of the extension using the phpize way will work.
>
>Now if I do a clean build and install of PHP without the module, 
>then try to build the module PHP via phpize, PHP can't load it. 
>Running nm on it reveals that the get_module function is not in the 
>.so file. I have traced the missing get_module function down to:
>
>#ifdef COMPILE_DL_FOO_BAR
>ZEND_GET_MODULE(foo_bar)
>#endif
>
>and COMPILE_DL_FOO_BAR is not defined at compile time.  This is not 
>defined because after running phpize config.h.in and configure are 
>different:
>
>--- config.h.in
>#undef COMPILE_DL_FOO_BAR
>
>---configure
>#define COMPILE_DL_FOOBAR 1
>
>It seems that the configure script is getting the underscore removed 
>from the module name.  From what I can tell this is done in 
>acinclude.m4 line 962:
>
>AC_DEFINE_UNQUOTED([COMPILE_DL_]translit($1,a-z-,A-Z_), 1, Whether 
>to build $1 as dynamic module)
>
>I think this needs to be changed to:
>
>AC_DEFINE_UNQUOTED([COMPILE_DL_]translit($1,a-z_-,A-Z_-), 1, Whether 
>to build $1 as dynamic module)
>
>This will handle extensions with both dashes and underscores, I think.
>
>I also find the same line in the aclocal.m4, so it may need changed there to.
>
>Am I off base here or is this a bug? I thought I would as before 
>submitting a bug report.
>
>Thanks,
>
>Brian
>
>BTW, no my extension is not named foo_bar, but it does have a underscore it.
>
>
>
>
>
>
>--
>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] Problems with extensions...

[Brian France]

Sorry ignore that last email it should read like this:

Brian
--

After reviewing my fix for this I realize that #define labels can 
only have A-Z and underscores so this is a better fix:

From:
AC_DEFINE_UNQUOTED([COMPILE_DL_]translit($1,a-z-,A-Z_), 1, Whether to 
build $1 as dynamic module)

To:
AC_DEFINE_UNQUOTED([COMPILE_DL_]translit($1,a-z_-,A-Z__), 1, Whether 
to build $1 as dynamic module)

Should I just submit a bug report on this or am I still missing something?

Thanks,

Brian

At 1:33 PM -0700 5/24/02, Brian France wrote:
>I am changing the way I build my PHP extension and am running into 
>some problems. I was originally would build it by copying the 
>directory foo_bar into the ext directory and added 
>--enable-foo_bar=shared to the configure line of PHP and build PHP. 
>Everything worked great!  Now I am looking to build it by:
>
>phpize
>./configure --enable-foo_bar=shared
>make
>
>If I build PHP with the module and install it, 
>include/php/main/php_config.h would have two lines in it:
>
>/*   */
>#define HAVE_FOO_BAR 1
>
>/* Whether to build foo_bar as dynamic module */
>#define COMPILE_DL_FOO_BAR 1
>
>And now any clean rebuilds of the extension using the phpize way will work.
>
>Now if I do a clean build and install of PHP without the module, 
>then try to build the module PHP via phpize, PHP can't load it. 
>Running nm on it reveals that the get_module function is not in the 
>.so file. I have traced the missing get_module function down to:
>
>#ifdef COMPILE_DL_FOO_BAR
>ZEND_GET_MODULE(foo_bar)
>#endif
>
>and COMPILE_DL_FOO_BAR is not defined at compile time.  This is not 
>defined because after running phpize config.h.in and configure are 
>different:
>
>--- config.h.in
>#undef COMPILE_DL_FOO_BAR
>
>---configure
>#define COMPILE_DL_FOOBAR 1
>
>It seems that the configure script is getting the underscore removed 
>from the module name.  From what I can tell this is done in 
>acinclude.m4 line 962:
>
>AC_DEFINE_UNQUOTED([COMPILE_DL_]translit($1,a-z-,A-Z_), 1, Whether 
>to build $1 as dynamic module)
>
>I think this needs to be changed to:
>
>AC_DEFINE_UNQUOTED([COMPILE_DL_]translit($1,a-z_-,A-Z_-), 1, Whether 
>to build $1 as dynamic module)
>
>This will handle extensions with both dashes and underscores, I think.
>
>I also find the same line in the aclocal.m4, so it may need changed there to.
>
>Am I off base here or is this a bug? I thought I would as before 
>submitting a bug report.
>
>Thanks,
>
>Brian
>
>BTW, no my extension is not named foo_bar, but it does have a underscore it.
>
>
>
>
>
>
>--
>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] Zend Engine unloading extension in the wrong order

[Brian France]

I have been tracking down a core dump with my php extension when it 
is unloading some of its shared libraries.  I have shared extension 
that is link against libexpat and will load fine if it is the only on 
in the php.ini.  If I then load xml.so extension then my extension it 
works fine, but if it is my extension then xml.so it crashes while 
xml.so is unloading libexapt.

What I have found is the Zend Engine is unloading extension in the 
same order it loaded them.

load: foo_bar.so
load: xml.so

unload: foo_bar.so
unload: xml.so

I believe this is wrong and think it should be in reverse order.

load: foo_bar.so
load: xml.so

unload: xml.so
unload: foo_bar.so


There are two ways to fix this problem.  One is to push the modules 
to the head of the hash, but looking at the zend_hash_add function I 
decided to go with the second.  Second way is to destroy them in 
reverse order.  I created a zend_hash_reverse_destroy and call that 
instead of zend_hash_destroy.  There may be a better way to do this, 
but this is the quick fix for me.

I have included a patch below, should I submit a bug report as well?

Thanks,

Brian


diff -rc php-4.2.1/Zend/zend.c
*** php-4.2.1/Zend/zend.c   Tue Feb 26 10:59:25 2002
--- php-4.2.1/Zend/zend.c   Thu Jun  6 11:32:57 2002
***
*** 487,493 
 zend_destroy_rsrc_list(&EG(persistent_list) TSRMLS_CC);
   #endif
 zend_destroy_rsrc_list_dtors();
!   zend_hash_destroy(&module_registry);
 zend_hash_destroy(GLOBAL_FUNCTION_TABLE);
 free(GLOBAL_FUNCTION_TABLE);
 zend_hash_destroy(GLOBAL_CLASS_TABLE);
--- 487,493 
 zend_destroy_rsrc_list(&EG(persistent_list) TSRMLS_CC);
   #endif
 zend_destroy_rsrc_list_dtors();
!   zend_hash_reverse_destroy(&module_registry);
 zend_hash_destroy(GLOBAL_FUNCTION_TABLE);
 free(GLOBAL_FUNCTION_TABLE);
 zend_hash_destroy(GLOBAL_CLASS_TABLE);
diff -rc php-4.2.1/Zend/zend_hash.c
*** php-4.2.1/Zend/zend_hash.c  Mon Apr 22 23:53:26 2002
--- php-4.2.1/Zend/zend_hash.c  Thu Jun  6 11:32:57 2002
***
*** 550,555 
--- 550,579 
 SET_INCONSISTENT(HT_DESTROYED);
   }

+ ZEND_API void zend_hash_reverse_destroy(HashTable *ht)
+ {
+   Bucket *p, *q;
+
+   IS_CONSISTENT(ht);
+
+   SET_INCONSISTENT(HT_IS_DESTROYING);
+
+   p = ht->pListTail;
+   while (p != NULL) {
+   q = p;
+   p = p->pLast;
+   if (ht->pDestructor) {
+   ht->pDestructor(q->pData);
+   }
+   if (!q->pDataPtr && q->pData) {
+   pefree(q->pData, ht->persistent);
+   }
+   pefree(q, ht->persistent);
+   }
+   pefree(ht->arBuckets, ht->persistent);
+
+   SET_INCONSISTENT(HT_DESTROYED);
+ }

   ZEND_API void zend_hash_clean(HashTable *ht)
   {

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Zend Engine expert wanted!!!!

[Brian France]

Zend Engine unloading extension in the wrong order! (Re-post due to 
no response)

I have been tracking down a core dump with my php extension when it 
is unloading some of its shared libraries.  I have shared extension 
that is link against libexpat and will load fine if it is the only on 
in the php.ini.  If I then load xml.so extension then my extension it 
works fine, but if it is my extension then xml.so it crashes while 
xml.so is unloading libexapt.

What I have found is the Zend Engine is unloading extension in the 
same order it loaded them.

load: foo_bar.so
load: xml.so

unload: foo_bar.so
unload: xml.so

I believe this is wrong and think it should be in reverse order.

load: foo_bar.so
load: xml.so

unload: xml.so
unload: foo_bar.so


There are two ways to fix this problem.  One is to push the modules 
to the head of the hash, but looking at the zend_hash_add function I 
decided to go with the second.  Second way is to destroy them in 
reverse order.  I created a zend_hash_reverse_destroy and call that 
instead of zend_hash_destroy.  There may be a better way to do this, 
but this is the quick fix for me.

I have included a patch below, should I submit a bug report as well?

Thanks,

Brian


diff -rc php-4.2.1/Zend/zend.c
*** php-4.2.1/Zend/zend.c   Tue Feb 26 10:59:25 2002
--- php-4.2.1/Zend/zend.c   Thu Jun  6 11:32:57 2002
***
*** 487,493 
 zend_destroy_rsrc_list(&EG(persistent_list) TSRMLS_CC);
   #endif
 zend_destroy_rsrc_list_dtors();
!   zend_hash_destroy(&module_registry);
 zend_hash_destroy(GLOBAL_FUNCTION_TABLE);
 free(GLOBAL_FUNCTION_TABLE);
 zend_hash_destroy(GLOBAL_CLASS_TABLE);
--- 487,493 
 zend_destroy_rsrc_list(&EG(persistent_list) TSRMLS_CC);
   #endif
 zend_destroy_rsrc_list_dtors();
!   zend_hash_reverse_destroy(&module_registry);
 zend_hash_destroy(GLOBAL_FUNCTION_TABLE);
 free(GLOBAL_FUNCTION_TABLE);
 zend_hash_destroy(GLOBAL_CLASS_TABLE);
diff -rc php-4.2.1/Zend/zend_hash.c
*** php-4.2.1/Zend/zend_hash.c  Mon Apr 22 23:53:26 2002
--- php-4.2.1/Zend/zend_hash.c  Thu Jun  6 11:32:57 2002
***
*** 550,555 
--- 550,579 
 SET_INCONSISTENT(HT_DESTROYED);
   }

+ ZEND_API void zend_hash_reverse_destroy(HashTable *ht)
+ {
+   Bucket *p, *q;
+
+   IS_CONSISTENT(ht);
+
+   SET_INCONSISTENT(HT_IS_DESTROYING);
+
+   p = ht->pListTail;
+   while (p != NULL) {
+   q = p;
+   p = p->pLast;
+   if (ht->pDestructor) {
+   ht->pDestructor(q->pData);
+   }
+   if (!q->pDataPtr && q->pData) {
+   pefree(q->pData, ht->persistent);
+   }
+   pefree(q, ht->persistent);
+   }
+   pefree(ht->arBuckets, ht->persistent);
+
+   SET_INCONSISTENT(HT_DESTROYED);
+ }

   ZEND_API void zend_hash_clean(HashTable *ht)
   {

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Zend Engine expert wanted!!!!

[Brian France]

The issue is *not* the order in which the Zend Engine is loading them 
in, but the order it is unloading them in.  Switching order for 
loading was a fix that just happened to work.  With the patch I 
provided I can put them in any order and it works.

Looking at the Apache source it keeps a list of loaded DSOs and when 
it loads one pushes it on to the head of the list.  This way when it 
iterates over the list to unload them it is in reverse order than it 
loaded them.  I have been told by a few co-workers that it is 
industry standard to unload in reverse order that you loaded, but I 
wanted at least one example so I looked at the Apache source.

Shouldn't the Zend Engine always unload extension in reverse order it 
loaded them in?

Thanks!

Brian

BTW,  I think the priority for loading in the ini should be an 
option, but a completely different subject.


At 12:12 PM -0700 6/7/02, brad lafountain wrote:
>  If this is your problem maybe a "offical" soultion to the problem should be
>thought. Like in your extension you can define a priority for loading and
>unloading your extension in the ini. Kinda like init.d.
>
>  Has there been any discussion about this topic before.
>
>  - brad
>
>--- Brian France <[EMAIL PROTECTED]> wrote:
>>  Zend Engine unloading extension in the wrong order! (Re-post due to
>>  no response)
>>
>>  I have been tracking down a core dump with my php extension when it
>>  is unloading some of its shared libraries.  I have shared extension
>>  that is link against libexpat and will load fine if it is the only on
>>  in the php.ini.  If I then load xml.so extension then my extension it
>>  works fine, but if it is my extension then xml.so it crashes while
>>  xml.so is unloading libexapt.
>>
>>  What I have found is the Zend Engine is unloading extension in the
>>  same order it loaded them.
>>
>>  load: foo_bar.so
>>  load: xml.so
>>
>>  unload: foo_bar.so
>>  unload: xml.so
>>
>>  I believe this is wrong and think it should be in reverse order.
>>
>>  load: foo_bar.so
>>  load: xml.so
>>
>>  unload: xml.so
>>  unload: foo_bar.so
>>
>>
>>  There are two ways to fix this problem.  One is to push the modules
>>  to the head of the hash, but looking at the zend_hash_add function I
>>  decided to go with the second.  Second way is to destroy them in
>>  reverse order.  I created a zend_hash_reverse_destroy and call that
>>  instead of zend_hash_destroy.  There may be a better way to do this,
>>  but this is the quick fix for me.
>>
>>  I have included a patch below, should I submit a bug report as well?
>>
>>  Thanks,
>>
>>  Brian
>>
>>
>>  diff -rc php-4.2.1/Zend/zend.c
>>  *** php-4.2.1/Zend/zend.c   Tue Feb 26 10:59:25 2002
>>  --- php-4.2.1/Zend/zend.c   Thu Jun  6 11:32:57 2002
>>  ***
>>  *** 487,493 
>>   zend_destroy_rsrc_list(&EG(persistent_list) TSRMLS_CC);
>> #endif
>>   zend_destroy_rsrc_list_dtors();
>>  !   zend_hash_destroy(&module_registry);
>>   zend_hash_destroy(GLOBAL_FUNCTION_TABLE);
>>   free(GLOBAL_FUNCTION_TABLE);
>>   zend_hash_destroy(GLOBAL_CLASS_TABLE);
>>  --- 487,493 
>>   zend_destroy_rsrc_list(&EG(persistent_list) TSRMLS_CC);
>> #endif
>>   zend_destroy_rsrc_list_dtors();
>>  !   zend_hash_reverse_destroy(&module_registry);
>>   zend_hash_destroy(GLOBAL_FUNCTION_TABLE);
>>   free(GLOBAL_FUNCTION_TABLE);
>>   zend_hash_destroy(GLOBAL_CLASS_TABLE);
>>  diff -rc php-4.2.1/Zend/zend_hash.c
>>  *** php-4.2.1/Zend/zend_hash.c  Mon Apr 22 23:53:26 2002
>>  --- php-4.2.1/Zend/zend_hash.c  Thu Jun  6 11:32:57 2002
>>  ***
>>  *** 550,555 
>>  --- 550,579 
>>   SET_INCONSISTENT(HT_DESTROYED);
>> }
>>
>>  + ZEND_API void zend_hash_reverse_destroy(HashTable *ht)
>  > + {
>  > +   Bucket *p, *q;
>  > +
>  > +   IS_CONSISTENT(ht);
>  > +
>  > +   SET_INCONSISTENT(HT_IS_DESTROYING);
>  > +
>  > +   p = ht->pListTail;
>  > +   while (p != NULL) {
>>  +   q = p;
>>  +   p = p->pLast;
>  > +   if (ht->pDestructor) {
>>  +   ht->pDestructor(q->pData);
>>  +   }
>>  +   if (!q->pDataPtr && q->pData) {
>>  +   pefree(q->pData, ht->persistent);
>>  +   }
>>  +   pefree(q, ht->persistent);
>>  +   }
>>  +   pefree(ht->arBuckets, ht->persistent);
>>  +
>>  +   SET_INCONSISTENT(HT_DESTROYED);
>>  + }
>>
>> ZEND_API void zend_hash_clean(HashTable *ht)
>> {
>>
>>  --
>>  PHP Development Mailing List <http://www.php.net/>
>>  To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
>
>__
>Do You Yahoo!?
>Yahoo! - Official partner of 2002 FIFA World Cup
>http://fifaworldcup.yahoo.com


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Zend Engine expert wanted!!!!

[Brian France]

I will try that, but I was worried that the pDestructor function 
would not get called for each item like it was in zend_hash_destroy. 
Is this the case?  Looking at the code what is the difference between 
zend_hash_graceful_destroy and zend_hash_destroy?

Thanks again for the help!

Brian

At 10:53 PM +0300 6/7/02, Andi Gutmans wrote:
>Can you check and see if using zend_hash_graceful_reverse_destroy() 
>fixes your problem?
>
>Andi
>
>At 11:44 AM 6/7/2002 -0700, Brian France wrote:
>>Zend Engine unloading extension in the wrong order! (Re-post due to 
>>no response)
>>
>>I have been tracking down a core dump with my php extension when it 
>>is unloading some of its shared libraries.  I have shared extension 
>>that is link against libexpat and will load fine if it is the only 
>>on in the php.ini.  If I then load xml.so extension then my 
>>extension it works fine, but if it is my extension then xml.so it 
>>crashes while xml.so is unloading libexapt.
>>
>>What I have found is the Zend Engine is unloading extension in the 
>>same order it loaded them.
>>
>>load: foo_bar.so
>>load: xml.so
>>
>>unload: foo_bar.so
>>unload: xml.so
>>
>>I believe this is wrong and think it should be in reverse order.
>>
>>load: foo_bar.so
>>load: xml.so
>>
>>unload: xml.so
>>unload: foo_bar.so
>>
>>
>>There are two ways to fix this problem.  One is to push the modules 
>>to the head of the hash, but looking at the zend_hash_add function 
>>I decided to go with the second.  Second way is to destroy them in 
>>reverse order.  I created a zend_hash_reverse_destroy and call that 
>>instead of zend_hash_destroy.  There may be a better way to do 
>>this, but this is the quick fix for me.
>>
>>I have included a patch below, should I submit a bug report as well?
>>
>>Thanks,
>>
>>Brian
>>
>>
>>diff -rc php-4.2.1/Zend/zend.c
>>*** php-4.2.1/Zend/zend.c   Tue Feb 26 10:59:25 2002
>>--- php-4.2.1/Zend/zend.c   Thu Jun  6 11:32:57 2002
>>***
>>*** 487,493 
>> zend_destroy_rsrc_list(&EG(persistent_list) TSRMLS_CC);
>>   #endif
>> zend_destroy_rsrc_list_dtors();
>>!   zend_hash_destroy(&module_registry);
>> zend_hash_destroy(GLOBAL_FUNCTION_TABLE);
>> free(GLOBAL_FUNCTION_TABLE);
>> zend_hash_destroy(GLOBAL_CLASS_TABLE);
>>--- 487,493 
>> zend_destroy_rsrc_list(&EG(persistent_list) TSRMLS_CC);
>>   #endif
>> zend_destroy_rsrc_list_dtors();
>>!   zend_hash_reverse_destroy(&module_registry);
>> zend_hash_destroy(GLOBAL_FUNCTION_TABLE);
>> free(GLOBAL_FUNCTION_TABLE);
>> zend_hash_destroy(GLOBAL_CLASS_TABLE);
>>diff -rc php-4.2.1/Zend/zend_hash.c
>>*** php-4.2.1/Zend/zend_hash.c  Mon Apr 22 23:53:26 2002
>>--- php-4.2.1/Zend/zend_hash.c  Thu Jun  6 11:32:57 2002
>>***
>>*** 550,555 
>>--- 550,579 
>> SET_INCONSISTENT(HT_DESTROYED);
>>   }
>>
>>+ ZEND_API void zend_hash_reverse_destroy(HashTable *ht)
>>+ {
>>+   Bucket *p, *q;
>>+
>>+   IS_CONSISTENT(ht);
>>+
>>+   SET_INCONSISTENT(HT_IS_DESTROYING);
>>+
>>+   p = ht->pListTail;
>>+   while (p != NULL) {
>>+   q = p;
>>+   p = p->pLast;
>>+   if (ht->pDestructor) {
>>+   ht->pDestructor(q->pData);
>>+   }
>>+   if (!q->pDataPtr && q->pData) {
>>+   pefree(q->pData, ht->persistent);
>>+   }
>>+   pefree(q, ht->persistent);
>>+   }
>>+   pefree(ht->arBuckets, ht->persistent);
>>+
>>+   SET_INCONSISTENT(HT_DESTROYED);
>>+ }
>>
>>   ZEND_API void zend_hash_clean(HashTable *ht)
>>   {
>>
>>--
>>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] Fwd: REJECTED:<5.1.0.14.2.20020607225328.03df2740@127.0.0.1>

[Brian France]

Somebody from PRESENCE-GROUP.COM is subscribed to php-dev list and is
filtering mail through spamcop or something program.  I am getting
them to.

Brian

At 10:58 PM +0300 6/7/02, Andi Gutmans wrote:
>Any idea why I got this when posting to php-dev?
>
>Andi
>
>>Delivered-To: [EMAIL PROTECTED]
>>Sender: <[EMAIL PROTECTED]> (reject)
>>Date: Thu, 06 Jun 2002 08:50:05 -0700
>>X-Autogenerated: Reply
>>To: Andi Gutmans <[EMAIL PROTECTED]>
>>From: [EMAIL PROTECTED]
>>Subject: REJECTED: <[EMAIL PROTECTED]>
>>X-Autogenerated: UNSOLICITED ELECTRONIC COMMUNICATION
>>Sender: [EMAIL PROTECTED]
>>Reply-To: [EMAIL PROTECTED]
>>Original-Message-ID: <[EMAIL PROTECTED]>
>>Original-Sender: Andi Gutmans <[EMAIL PROTECTED]>
>>Original-Subject: Re: [PHP-DEV] Zend Engine expert wanted
>>Original-Date: Fri, 07 Jun 2002 22:53:42 +0300
>>
>>
>>SERVICE of LEGAL NOTICE:
>>
>>Pursuant to California Law (cref. California Business & Professions Code
>>§§ 17538.4, 17538.45 (2001)), the message referenced herein, uniquely
>>identified by the following Internet messaging headers:
>>
>> {
>> Original-Message-ID:
>><[EMAIL PROTECTED]>
>> Original-Sender: Andi Gutmans <[EMAIL PROTECTED]>
>> Original-Subject: Re: [PHP-DEV] Zend Engine expert wanted
>> Original-Date: Fri, 07 Jun 2002 22:53:42 +0300
>> }
>>
>>has been categorized as either Unsolicited Bulk E-mail (UBE), or
>>Unsolicited Commercial E-Mail (UCE).
>>
>>Your server is one of those included in the headers of the message, and
>>thus has been deemed an offending server used in the delivery of
>>this message.
>>
>>California Law establishes Civil Right of Action against violators:
>>
>> "In addition to any other action available under law, any
>> electronic mail service provider whose policy on unsolicited
>> electronic mail advertisements is violated as provided in this
>> section may bring a civil action to recover the actual monetary loss
>> suffered by that provider by reason of that violation, or liquidated
>> damages of fifty dollars ($50) for each electronic mail message
>> initiated or delivered in violation of this section, up to a maximum
>> of twenty-five thousand dollars ($25,000) per day, whichever amount
>> is greater."
>>
>>Your cooperation, as outlined below, is REQUIRED by California Law.
>>
>>To avoid being cited as an accomplice in this matter, PRESENCE-GROUP.COM
>>requires you to take immediate and appropriate actions to stop the problem
>>in the future. You are to notify us within three (3) days of those actions.
>>Our experience shows that all legitimate Internet providers take
>>immediate action.
>>
>>If your server is an offending server in the *origination* of this message,
>>PRESENCE-GROUP.COM demands that you provide us with the name, mailing address
>>and other contact information of the originator of this message.
>>If you furnish PRESENCE-GROUP.COM with this information, PRESENCE-GROUP.COM
>>will release you from liability in this incident. Merely telling us you have
>>cancelled or deleted the account is *not* adequate to satisfy the
>>PRESENCE-GROUP.COM policy.
>>
>>If your server is an offending server in the *relay* of this message,
>>PRESENCE-GROUP.COM demands that you take measures to stop the "open relay"
>>from your insecure mailserver.
>>
>>If you do not furnish PRESENCE-GROUP.COM with the information we
>>have requested,
>>or provide us only with auto-responder or form messages,
>>PRESENCE-GROUP.COM will
>>consider how often your server is involved with UBE/UCE. We may then:
>>
>> 1. Block access to & from your server.
>> 2. Deem you to be a co-conspirator in the delivery of
>>UBE/UCE messages.
>> 3. Hold you liable for fees & damages.
>>
>>There is no need for you to send your appropriate use policy to us;
>>As stated by law,
>>it is our policy that governs.
>>
>>In order to provide required response to this notice, or if you
>>believe you have
>>received this notice in error, please forward your communication to:
>>"[EMAIL PROTECTED]", with the words "SPAM EXCEPTION"
>>exactly included in
>>the message Subject: header.
>>
>>Further, you may choose to notify your intended recipient by an additional,
>>alternate method requesting that they address this matter with the
>>PRESENCE-GROUP.COM mail server administrator.
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Zend Engine expert wanted!!!!

[Brian France]

Yes, zend_hash_graceful_reverse_destroy() fixes the problem as well. 
Is this a better solution for the fix?

Thanks,

Brian

At 11:06 PM +0300 6/7/02, Andi Gutmans wrote:
>At 01:00 PM 6/7/2002 -0700, Brian France wrote:
>>I will try that, but I was worried that the pDestructor function 
>>would not get called for each item like it was in 
>>zend_hash_destroy. Is this the case?  Looking at the code what is 
>>the difference between zend_hash_graceful_destroy and 
>>zend_hash_destroy?
>
>Yeah the destructor should be called. The graceful_destroy() is just 
>a bit more careful and used when destroying the resource list.
>
>Andi
>
>
>--
>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] Zend Engine expert wanted!

[Brian France]

At 2:57 AM +0300 6/8/02, Zeev Suraski wrote:
>We're on the job.  I generally think you're right, we have to do 
>some more thinking but chances are we will change the shutdown order 
>to be reversed.

Just a FYI, may want to do the same for zend_extension (reverse 
order).  I think that is a zend_llist instead of a zend_hash, but I 
believe it unloads in the same order they are loaded instead of 
reverse.

>Sorry for not ack'ing earlier.

No problem, just glad I confirmed the fix.  Thanks for help!

Cheers,

Brian

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: cvs: php4 /ext/mbstring mbstring.c

[Brian France]

Ok, what does exif need from mbstring, code wise?  Taking a look at
it I don't see any references to mbstring in the code.

Thanks,

Brian

At 8:27 PM +0200 6/20/02, Marcus Börger wrote:
>You will break ext/exif when removing mbstrings current integration
>
>At 04:17 20.06.2002, you wrote:
>>I am testing a patch that allows mbstring to be built as a shared
>>extension instead of static.  This would allow removing any
>>reference to mbstring from the core PHP code and making mbstring
>>movable out of the ext directory possible.  Not that moving it out
>>needs to happen, but as much talk about moving things out of the
>>ext directory I thought it would be a selling point :-)
>>
>>The patch basically renames php_treat_data to
>>php_treat_data_default, creates a function pointer called
>>php_treat_data that is defaulted to php_treat_data_default, removes
>>all mbstrings references in php_main.h and makes mbstring.c change
>>the php_treat_data to mbstr_treat_data in the INIT function and
>>restores its value in SHUTDOWN.
>>
>>Would you be interested in it?
>>
>>Thanks,
>>
>>Brian
>>
>>At 10:36 AM +0900 6/20/02, Yasuo Ohgaki wrote:
>>>Marcus BöRger wrote:
helly   Wed Jun 19 17:55:46 2002 EDT

   Modified files:
 /php4/ext/mbstring  mbstring.c   Log:
   correct handling/generating of php_mbstr_default_identify_list
>>>
>>>As I posted before, I'll try merge changes made in php4/ext/mbstring
>>>to PHP i18n project repository's source. Please note that I'm not
>>>promising that for sure.
>>>
>>>mbstring source has been modified a lot.
>>>Please check http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/php-i18n/
>>>to avoid duplicated work or to make sure your work is included.
>>>
>>>--
>>>Yasuo Ohgaki
>>>
>>>
>>>
>>>--
>>>PHP Development Mailing List 
>>>To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>>--
>>PHP Development Mailing List 
>>To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: cvs: php4 /ext/mbstring mbstring.c

[Brian France]

I was just using the ability to remove mbstring from ext as a selling 
point to get the patch into PHP. Stays or goes is up to you guys. :-) 
What I am doing for work is setting up a bare PHP that can be 
installed on all server and then who ever needs mbstring, xml, xslt 
or what ever extension can just load that shared extension.  This way 
you only load what you need and nothing you don't.

I haven't been able to get the session extension built as shared, any 
tips on that? Or the mysql for that matter.  Yes adding 
--with-mysql=shared to PHP's configure builds a shared .so, but it is 
rather small compared to the one if you build it with phpize, 
./configure, make in the ext/mysql directory.

Thanks,

Brian

At 8:44 AM +0900 6/21/02, Yasuo Ohgaki wrote:
>Brian France wrote:
>>Ok, what does exif need from mbstring, code wise?  Taking a look at 
>>it I don't see any references to mbstring in the code.
>>
>
>exif needs mbstring to handle multibyte chars.
>
>IMO, removing mbstring from PHP is ok as long as user
>knows what they are doing. We can remove other internal
>modules, such as session module also.
>
>--
>Yasuo Ohgaki


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: cvs: php4 /ext/mbstring mbstring.c

[Brian France]

My goal is NOT TO REMOVE mbstring FROM THE ext DIRECTORY.  Here is
what I do want:

I build php for tens of thousands of web servers.  Those servers are
all over the world.  I only want to build one default PHP core apache
module that only has the standard core things and then everything
else as shared extensions.  This way all the servers in the US don't
have to include mbstring, but the server in JP can add one line in
the php.ini to load mbstring and use it.  Another example is why do
all of the server have to have xml/xslt in their PHP module when only
a very few will be using it, this way those few can edit php.ini and
load the extension.

I would like to make a suggestion on extension in the ext directory.
If your extension is not in the standard directory, then you should
to be able to be built both statically and shared from *BOTH* the PHP
./configure line and using phpize, ./configure, make methods.  I know
of 2 modules that can not be built shared from the PHP ./configure
line, but I do believe work with the phpize method.  I will be
sending another message about today about mysql, the other is
sessions.

I guess my sales pitch of "can be removed from ext" back fired. :-)
Should of just stuck with "can be built as a shared extension".

Thanks,

Brian

At 1:57 PM +0100 6/21/02, Wez Furlong wrote:
>mailparse (now in PECL) also requires that mbstring be installed.
>More specifically, it requires that the mbstring headers are installed
>in the pear header directory when building it (mailparse) as a SCE.
>
>Also, isn't the new multibyte support in ZE dependent on mbstring in
>some way? (I'm just guessing here, so excuse me if I am wrong)
>
>We really need to make sure that pear/pecl installs relevant headers
>for SCEs when they are built, so that other SCE will work nicely too.
>
>If you do decouple mbstring, please make sure that the mbstring headers
>are still installed in the pear include directory too!
>
>--Wez.
>
>On 20/06/02, "Brian France" <[EMAIL PROTECTED]> wrote:
>>  Ok, what does exif need from mbstring, code wise?  Taking a look at
>>  it I don't see any references to mbstring in the code.
>>
>>  Thanks,
>>
>>  Brian
>>
>>  At 8:27 PM +0200 6/20/02, Marcus Börger wrote:
>>  >You will break ext/exif when removing mbstrings current integration
>>  >
>>  >At 04:17 20.06.2002, you wrote:
>>  >>I am testing a patch that allows mbstring to be built as a shared
>>  >>extension instead of static.  This would allow removing any
>>  >>reference to mbstring from the core PHP code and making mbstring
>>  >>movable out of the ext directory possible.  Not that moving it out
>>  >>needs to happen, but as much talk about moving things out of the
>>  >>ext directory I thought it would be a selling point :-)
>>  >>
>>  >>The patch basically renames php_treat_data to
>>  >>php_treat_data_default, creates a function pointer called
>>  >>php_treat_data that is defaulted to php_treat_data_default, removes
>>  >>all mbstrings references in php_main.h and makes mbstring.c change
>>  >>the php_treat_data to mbstr_treat_data in the INIT function and
>>  >>restores its value in SHUTDOWN.
>>  >>
>>  >>Would you be interested in it?
>>  >>
>>  >>Thanks,
>>  >>
>>  >>Brian
>>  >>
>>  >>At 10:36 AM +0900 6/20/02, Yasuo Ohgaki wrote:
>>  >>>Marcus BöRger wrote:
>>  >>>>helly   Wed Jun 19 17:55:46 2002 EDT
>>  >>>>
>>  >>>>   Modified files:
>>  >>>> /php4/ext/mbstring  mbstring.c   Log:
>>  >>>>   correct handling/generating of php_mbstr_default_identify_list
>>  >>>
>>  >>>As I posted before, I'll try merge changes made in php4/ext/mbstring
>>  >>>to PHP i18n project repository's source. Please note that I'm not
>>  >>>promising that for sure.
>>  >>>
>>  >>>mbstring source has been modified a lot.
>>  >>>Please check http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/php-i18n/
>>  >>>to avoid duplicated work or to make sure your work is included.
>  > >>>
>  > >>>--
>  > >>>Yasuo Ohgaki
>  > >>>
>  > >>>
>  > >>>
>  > >>>--
>  > >>>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
>
>
>
>
>--
>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] Re: cvs: php4 /ext/mbstring mbstring.c

[Brian France]

At 6:57 PM +0100 6/21/02, Wez Furlong wrote:
>  > >If you do decouple mbstring, please make sure that the mbstring headers
>  > >are still installed in the pear include directory too!
>
>If mbstring is built as a shared extension, you need to ensure that it's
>headers are also installed in the pear header directory, otherwise configuring
>other modules that depend upon it will fail.

Not a problem, all headers are install by our packaging system even 
if the extension is not compiled into our core PHP package.

Brian

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: cvs: php4 /ext/mbstring mbstring.c

[Brian France]

At 7:23 PM +0200 6/21/02, Marcus Börger wrote:
>What i wanted to stree out is that exif uses functions from mbstring
>if present.
>That means if mbstring is not present it does not use these and the
>user has to do that stuff for his own.
>If mbstring is compiled as a shared extension both exif and mbstring
>will work together perfectly but exif cannot use mbstring even
>though it is present and that might/WILL be confusing to users.

That make sense, is there a change that can be made in exif to fix
this problem?  Looking over the code for exif again I still don't see
it calling anything from mbstring and it doesn't call php_treat_data
which was what mbstring was overwriting.

Cheers,

Brian

--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: cvs: php4 /ext/mbstring mbstring.c

[Brian France]

At 9:56 PM +0200 6/21/02, Marcus Börger wrote:
>At 20:29 21.06.2002, Brian France wrote:
>>At 7:23 PM +0200 6/21/02, Marcus Börger wrote:
>>>What i wanted to stree out is that exif uses functions from
>>>mbstring if present.
>>>That means if mbstring is not present it does not use these and
>>>the user has to do that stuff for his own.
>>>If mbstring is compiled as a shared extension both exif and
>>>mbstring will work together perfectly but exif cannot use mbstring
>>>even though it is present and that might/WILL be confusing to
>>>users.
>>
>>That make sense, is there a change that can be made in exif to fix
>>this problem?  Looking over the code for exif again I still don't
>>see it calling anything from mbstring and it doesn't call
>>php_treat_data which was what mbstring was overwriting.
>>
>
>It uses c functions php_mb_convert_encoding and
>php_mb_check_encoding_list. If you do not find those in
>ext/exif/exif.c you are not using head since this was added right
>after releasing PHP 4.2. In there you'll
>find some #ifdef HAVE_MBSTRING lines.

Ah, it all because clear, yes I am using the 4.2.1 for all of our
packages (plus our own patch fixes) so I don't see any of the those
changes.

>I think if you use PHP 4.2.x for now we will find a solution like
>Markus (with k) mentioned and load the needed
>two functions dynamically.

Great, our goal is to use the PHP source as is and not making large
changes to it which would force us to stick with one version or
merger patches to the next version which becomes a nightmare (lessons
learned from hacking apache source).

Thanks!

Brian

--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] session can't be built shared with PHP

[Brian France]

I have been trying to build session support as a shared extension and 
here is what I have found.  It works fine if you us the phpize, 
./configure, make method, but if you try building it shared while 
building PHP it will not work.

./configure --with-layout=GNU --enable-session=shared --with-mm=shared
 (it works)
make
(while compiling main/internal_functions.c)
internal_functions.c:47: `phpext_ps_mm_ptr' undeclared here (not in a function)
internal_functions.c:47: initializer element is not constant
internal_functions.c:47: (near initialization for `php_builtin_extensions[6]')

--- internal_functions.c ---
zend_module_entry *php_builtin_extensions[] = {
 phpext_xml_ptr,
 phpext_standard_ptr,
 phpext_posix_ptr,
 phpext_pcre_ptr,
 phpext_mysql_ptr,
 phpext_ctype_ptr,
  phpext_ps_mm_ptr,
};


It seems that phpext_ps_mm_ptr gets added if --with-mm or 
--with-mm=shared is set.  Adding it with  --with-mm=shared is bad as 
it is not needed and doesn't include the right headers for that 
function anyway.  I have created a patch to fix this, but wanted to 
make sure this was the best way to fix it.  Is there a better way? 
Comments?

Thanks,

Brian

BTW,
   ./configure --with-layout=GNU --enable-session=shared --with-mm=no
and
   ./configure --with-layout=GNU --enable-session=shared --without-mm
will not build it shared either, but I am not worried about that.

 Patch

--- php-4.2.1/configure Mon Jun 24 14:15:58 2002
+++ php-4.2.1/configure Mon Jun 24 14:16:36 2002
@@ -57197,9 +57197,9 @@
  #define HAVE_LIBMM 1
  EOF

-
-  EXTRA_MODULE_PTRS="$EXTRA_MODULE_PTRS phpext_ps_mm_ptr,"
-
+  if test "$ext_shared" != "yes"; then
+EXTRA_MODULE_PTRS="$EXTRA_MODULE_PTRS phpext_ps_mm_ptr,"
+  fi
  fi

  if test "$PHP_SESSION" != "no"; then

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] patch for ext/session

[Brian France]

Does this fix the problem with configure?

http://bugs.php.net/bug.php?id=17977

I take it if session is shared then mm is shared as well, right?

Also will this "--enable-session=shared --without-mm" still allow 
session to be shared?

Thanks,

Brian

At 9:38 PM +0300 6/26/02, Jani Taskinen wrote:
> The attached patch fixes the problems when
> you build session extension as shared and MM.
>
> (--enable-session=shared --with-mm)
>
> Also adds a list of registered save handlers
> to the phpinfo() output.
>
> Please test/review. It works fine here,
> as shared and as static. Now the mm module is treated
> like the other external handlers..

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] patch for ext/session

[Brian France]

Great!

Once the patch is checked in feel free to close the bug report or let 
me know and I will close it.

Thanks!

Brian

At 9:59 PM +0300 6/26/02, Jani Taskinen wrote:
>On Wed, 26 Jun 2002, Brian France wrote:
>
>>Does this fix the problem with configure?
>>
>>http://bugs.php.net/bug.php?id=17977
>
> yes..
>
>>I take it if session is shared then mm is shared as well, right?
>
> It makes the mm module not to be an extension of itself..
> which it really isn't, as it's only a module for session.
>
> Short answer: Yes. --with-mm=shared is same as --with-mm
>
>>Also will this "--enable-session=shared --without-mm" still allow
>>session to be shared?
>
> Oh..didn't test that one, but yes, it should still allow
> it to be shared. (actually..I think that was fixed by Sascha
> a while ago in CVS)

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Key values starting with .

[Brian France]

Hello,

   I have a url that ends with ?.value=1, but PHP returns this in 
$_REQUEST as _value instead of .value.  I believe this is because of 
this code:

main/php_variables.c
104 /* ensure that we don't have spaces or dots in the 
variable name (not binary safe) */
105 for (p=var; *p; p++) {
106 switch(*p) {
107 case ' ':
108 case '.':
109 *p='_';
110 break;
111 }
112 }


I can do this: $_REQUEST['.name'] = "testing" then if I do 
print_r($_REQUEST) prints it out as .value and not _value.  Any 
reason for being able to do one, but not the other?  Also what is the 
"(not binary safe)" part of a variable with a . in its name?

Thanks,

Brian

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring

[Brian France]

At 9:00 PM +0200 7/17/02, [EMAIL PROTECTED] wrote:
>On Wed, 17 Jul 2002, Jani Taskinen wrote:
>  > Can't they be merged and use #ifdef's to enable
>  > the multibyte support?

Personally I don't like the idea of having a module change the PHP 
core code with a #ifdef like mbstring does now.  I would rather see 
the module change a function pointer to its handler, add its function 
handler to a list of function handlers or have the default code 
handle multi-byte strings,  as long as there is not a large size, 
speed or memory increase doing it.

Just my 2 cents. :-)

Brian

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php