Hi,
The config is:
PHP_ARG_WITH(carbonae, for carbonae support,
[ --with-carbonae Include Carbon Apple Events support])
if test "$PHP_CARBONAE" != "no"; then
if test "`(uname) 2>/dev/null`" != "Darwin"; then
AC_MSG_ERROR([--with-carbonae can only be used on Mac OS X
systems.])
On Thu, 7 Apr 2005, Brian J. France wrote:
Looks like there might be some problems with your patch to phpize.in for
lines:
+ if ! test -x "$php_shtool path $PHP_AUTOCONF"; then
and
+ if ! test -x "$php_shtool path $PHP_AUTOHEADER"; then
shouldn't those double quotes be back-ticks?
Actually
Looks like there might be some problems with your patch to phpize.in
for lines:
+ if ! test -x "$php_shtool path $PHP_AUTOCONF"; then
and
+ if ! test -x "$php_shtool path $PHP_AUTOHEADER"; then
shouldn't those double quotes be back-ticks?
Also echo and here documents are not working on my syste
On Thu, 7 Apr 2005, Brian J. France wrote:
On Apr 7, 2005, at 1:28 AM, Jani Taskinen wrote:
I made some changes to phpize now. But not using your
patch since that would not have worked everywhere.
Cool, changes look good. What about getting Jon's original patch and this
change back ported
On Apr 7, 2005, at 1:28 AM, Jani Taskinen wrote:
I made some changes to phpize now. But not using your
patch since that would not have worked everywhere.
Cool, changes look good. What about getting Jon's original patch and
this change back ported?
Searching for these tools is _still_
Hello Alan,
it seems you are registering constants on an internal class. If so
you must use the correct api since your data must be allocated by
malloc instead of emalloc. In your codes i can only see regular stuff
that uses emalloc so it must go wrong.
marcus
Thursday, April 7, 2005, 5:10:53
I'm using the code below to register object constants, however I'm
getting a memory leak on the line shown.. , any ideas how to avoid this?
/var/svn_live/dbdo/dbdo.c(401) : Freeing 0x0860FC34 (16 bytes),
script=examples/info.php
#define hash_add_assoc_long(__arg, __key, __val)
hash_add_assoc_lon
On Thu, 7 Apr 2005, Zeev Suraski wrote:
> @@ -80,7 +80,7 @@ ZEND_API void *_erealloc(void *ptr, size
> ZEND_API char *_estrdup(const char *s ZEND_FILE_LINE_DC
> ZEND_FILE_LINE_ORIG_DC) ZEND_ATTRIBUTE_MALLOC;
> ZEND_API char *_estrndup(const char *s, unsigned int length ZEND_FILE_LINE_DC
> ZEND_F
/patches/zend-alloc-strndup-20050407.patch
This is because estrdup needs to allocate one more byte than the length
and you can't do that differently with strdup. I'd like to commit this
patch to all branches.
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://
Hello Andi,
the following patch fixes issues when ZEND_ALLOC is set to 0 (to be able
to debug memory related issues in / with the engine):
http://files.derickrethans.nl/patches/zend-alloc-strndup-20050407.patch
This is because estrdup needs to allocate one more byte than the length
and you
> If there's something that looks like a scheme (i.e., a well-formed
> sequence of
> characters followed by ':'),
> see if it's registered;
> if it is,
> the appropriate wrapper should be used.
> Otherwise,
> on platforms where ':' has signifi
I am fixing bug #32614: Problem, on the solaris platform fdopen() can fail
even if fd is a correct file descriptor, when fd>255 (the well-known
solaris stdio problem). The webserver of the user crashes because the
return value of fdopen() is not checked for NULL when casting a stream from
posix
12 matches
Mail list logo
