I found this late last week and haven't had time to open a bug, but after
seeing the EOL thread on 5.3 (5.3.27) wanted to see if anybody knew what might
be causing it:
#0 0x005dffeb in gc_zval_possible_root (zv=0x7ff3cdc19010) at
php-5.3.27/Zend/zend_gc.c:143
#1 0x005d10c2 in
Was the change that went into 5.3.24 and 5.3.14 a major compatible change that
should be backed out and put into in 5.5/5.6 or a simple bug fix that is ok in
a patch release?
Example code:
User Space -
?php
X_SET_ERROR('NONE');
try
{
$param = 1;
X_FUNC($parm1);
}
Could you explain the use case for this? Just for my own curiosity, I am sure
you have a valid reason for it.
I have always found that only bad things happen when you let
extensions/modules/shared libs stay loaded during the double load of apache.
Thanks!
Brian
On Mar 6, 2012, at 6:19
:
*** [sapi/cli/php] Error 1
Thanks for further help,Rwe
--- On Sun, 1/17/10, Brian J. France br...@brianfrance.com wrote:
From: Brian J. France br...@brianfrance.com
Subject: Re: [PHP-DEV] Can we call Apache 2 API function from a PHP 5
extension module?
To: rwe rt rwe...@yahoo.com
Cc: internals
Try this instead:
request_rec *r = (request_rec *)(((SG(server_context) == NULL) ? NULL :
((php_struct*)SG(server_context))-r));
Apache 2.x server_context is not a request_rec, it is a struct with a request
rec in it.
Brian
On Jan 16, 2010, at 7:25 PM, rwe rt wrote:
Hi all,I compiled
Anybody have a problem with me committing the patch below?
We still use 2.9.5 for our FreeBSD builds (ya, I know its old) and
while building extensions we get:
Zend/zend.h:379: warning: `always_inline' attribute directive ignored
Zend/zend.h:383: warning: `always_inline' attribute directive
Hi,
Currently there isn't a way to add http headers into a soap
request. Below is a patch to get headers from the passed in context
(code taken from ext/standard/http_fopen_wrapper.c). Doing something
like this:
$opts = array('http' = array('header' = 'X-foo: bar'));
$ctx =
After some more testing I needed to tweak the patch and the example,
here is version 2.
$opts = array('http' = array('header' = 'X-foo: bar'));
$ctx = stream_context_create($opts);
Brian
--- ext/soap/php_http.c.orig2008-09-26 05:39:50.0 -0700
+++ ext/soap/php_http.c 2008-09-26
On Jul 29, 2008, at 4:52 AM, Alejandro Leiva wrote:
I'm working in porting php to cmake there is information in the
wiki @ http://wiki.php.net/internals/cmake, now is compiling Zend,
main, TSRM, ext/ctype, ext/date, ext/dom, ext/libxml, ext/phar, ext/
standard and sapi/cli. I wrote a php
On Nov 3, 2006, at 8:20 AM, Joe Orton wrote:
On Fri, Oct 27, 2006 at 12:12:46PM -0400, Brian J. France wrote:
and I plan on removing it from our internal builds as it causes more
problems than I think it fixes (on RHEL only).
Hi, what problems do you see from the use of RTLD_DEEPBIND?
Where
On Oct 27, 2006, at 11:57 AM, Michael B Allen wrote:
Is there any way to determine exactly which version of PHP first
used the
RTLD_DEEPBIND flag to dlopen(3)? Can webcvs be used somehow. I *think*
it's between 4.3 and 4.4 but I'm not sure.
4.4:
On Oct 27, 2006, at 1:07 PM, Michael B Allen wrote:
On Fri, 27 Oct 2006 12:12:46 -0400
Brian J. France [EMAIL PROTECTED] wrote:
On Oct 27, 2006, at 11:57 AM, Michael B Allen wrote:
Is there any way to determine exactly which version of PHP first
used the
RTLD_DEEPBIND flag to dlopen(3)? Can
I think the xml stuff in php_compat.h needs some attention.
The gd defines need moved out side of the xml stuff and only things
from expat_compat.h need compat'ed.
This patch is what I was thinking:
http://www.brianfrance.com/software/php/php_compat.h.patch
This also adds one that is used
Could the curl_multi_info_read patch be considered for the 5.2 branch?
Thanks,
Brian
On May 6, 2006, at 6:27 PM, Ilia Alshanetsky wrote:
I've just created the PHP 5.2 branch from which future 5.X release
will be made, so please update your local trees to this branch. The
5.1 branch is
Some guys at work created this patch and have been running with it
for a while now.
Could I get a few more eyeballs on this?
http://www.brianfrance.com/software/php/curl_multi_read.patch
Quote from our internal bug:
The attached patch implements curl_multi_info_read(), as well as
fixing
PHP_5_1 and head or just head?
It could be considered bug fix since curl_multi_info_read was there,
but not implemented.
Brian
On May 2, 2006, at 4:56 PM, Sterling Hughes wrote:
please commit it, looks good.
thanks,
sterling
On 5/2/06, Brian J. France [EMAIL PROTECTED] wrote:
Some guys
On Mar 10, 2006, at 1:57 AM, Rasmus Lerdorf wrote:
Rasmus Lerdorf wrote:
Andi Gutmans wrote:
Are you sure VCWD_REALPATH doesn't use the realpath cache? It did
last time I checked and I think is still the right method to use
there...
quite
#define VCWD_REALPATH(path, real_path)
Does anybody see a problem with this patch (which is currently
against the 5.1.2 release)?
expand_filepath will eventual do a realpath, but it also uses the
realpath cache before calling realpath. VCWD_REALPATH just maps
directly to realpath and doesn't use the realpath cache so for every
I just tracked down a problem in the session extension and it looks
like it was caused by a patch not getting merged back to head (which
became PHP_5_1).
This patch:
http://cvs.php.net/viewcvs.cgi/php-src/ext/session/session.c?
view=logpathrev=PHP_4_4#rev1.336.2.40
is missing from
The following patch is need if phpize is going to be used to build
ext/gd with the bundled libgd library.
Otherwise HAVE_GD_BUNDLED will not be set for the bundled lib so it
will not build with the php_gd_ prefix, but the extension will have
HAVE_GD_BUNDLED defined and expecting the php_gd_
On Aug 11, 2005, at 7:48 PM, steve roussey wrote:
o Apache 2+ uses SO_LINGER by default if it defined for that system.
Really? We just did a around of discussion/debugging on this at work
and I found that it uses ap_lingering_close which is like the
lingering_close function in 1.3.
On Aug 12, 2005, at 10:52 AM, steve roussey wrote:
On 8/12/05, Brian J. France [EMAIL PROTECTED] wrote:
Really? We just did a around of discussion/debugging on this at work
and I found that it uses ap_lingering_close which is like the
lingering_close function in 1.3.
:)
Yes, it does do
Was the removal of most pear package in 4.3.11 intentional?
Will any of them come back, will any of the .11 packages be removed or
an other changes coming?
Don't care either way, just want to know what the plan is.
Thanks,
Brian
# ls -alF php-4.3.1?/pear/packages/
php-4.3.10/pear/packages/:
Anybody see a problem with this patch that allows .cc files in shared
extensions.
If not I will check it into all branches.
Thanks,
Brian
Index: acinclude.m4
===
RCS file: /repository/php-src/acinclude.m4,v
retrieving revision
On Tue, 19 Apr 2005, Brian J. France wrote:
Anybody see a problem with this patch that allows .cc files in shared
extensions.
If not I will check it into all branches.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
(FreeBSD).
cat seems to work with here docs.
# bash --version
GNU bash, version 2.05a.0(1)-release (i386-unknown-freebsd4.3)
Copyright 2001 Free Software Foundation, Inc.
Brian
On Apr 7, 2005, at 3:49 PM, Jani Taskinen wrote:
On Thu, 7 Apr 2005, Brian J. France wrote:
On Apr 7, 2005, at 1:28 AM
On Apr 4, 2005, at 12:35 AM, Jon Parise wrote:
Apologies if this got lost amongst the effort to prepare the recent
set of releases, but I'm curious whether or not people find my second
patch acceptable, based on the results of the prior discussion. If
not, I'll know to abandon the issue.
Here is
Ok, lets try this:
http://www.brianfrance.com/patch.build
Brian
On Apr 6, 2005, at 7:19 PM, Brian J. France wrote:
On Apr 4, 2005, at 12:35 AM, Jon Parise wrote:
Apologies if this got lost amongst the effort to prepare the recent
set of releases, but I'm curious whether or not people find my
Is there a easy way to change the internal soname?
I need to build the embeded sapi with a different internal soname.
Yes, I can rename libphp4.so (the embeded version) to libphp4-embed.so,
but things that link with libphp4-embed.so will have a dependency of
libphp.so because that is what the
I have already run this past Sterling, but figured I would make sure
there are no other objections to applying this patch to both 4.3 and
HEAD.
It allows switching back to the standard output by calling:
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 0);
Thanks,
Brian
Based on 4.3.4 source
True, but I had a group request it and tested the patch so I figured I
would see about giving it back.
Brian
On Feb 24, 2004, at 6:01 PM, Ilia Alshanetsky wrote:
Why is this needed?
As far as I know curl extension already prints to screen by default.
The only
instance where this maybe useful,
If there are no objections I plan on committing this tomorrow on both HEAD and
PHP_4_3 branches. This fixes the openssl FreeBSD problem I posted about
earlier.
Is there a better way of fixing it?
Brian
Index: acinclude.m4
===
On Thu, 13 Nov 2003 16:19:23 +0200 (EET), Jani Taskinen wrote:
On Wed, 12 Nov 2003, Brian J. France wrote:
Yes, you shouldn't pollute LIBS like that. :)
I committed a bit better fix for this.
Thank you!
Hint: Don't compile extensions as shared..it really doesn't give
you
I am having a problem building snmp as a shared extension since the move to
PHP_SETUP_OPENSSL.
The big problem is libssl.so on FreeBSD doesn't have a dependence on
libcrypt.so, but I don't think I can get fixed anytime soon.
When running ./configure for the shared extension it fails for the
Should have read the diff more closely, this message was a bit
misleading:
Changed setcookie to turn on the URL encoding of the cookie data
Ya, I probably shouldn't have mentioned the setcookie change since it was so
minor.
Yeah I know. I'll go whack Brian and learn him
Here is a patch, it is actually two lines that need changed.
Thanks,
Brian
On Thu, 14 Aug 2003 00:17:11 +0200 (CEST), Sascha Schumann wrote:
Did something change recently to cause this? If nobody sees a
problem with the change I am going to check it in.
There are some translit
I am having problem building extension with long names. As an example say my
extension name is f_name_bar and
F_NAME_BAR_SHARED_LIBADD is used to link libraries.
The problem is when the Makefile is generated I get
F_NAME_BAR_SHARED_LIBADD at the top of the
38 matches
Mail list logo
