The "state" parameter passed to SQLGetDiagRec() needs to be six bytes
not 5; the attached patch fixes this, from Martin Osvald.
diff --git a/ext/pdo_odbc/odbc_driver.c b/ext/pdo_odbc/odbc_driver.c
index 84a147b..ca2808c 100755
--- a/ext/pdo_odbc/odbc_driver.c
+++ b/ext/pdo_odbc/odbc_driver.c
@@ -1
The check to prevent extract() overwriting $GLOBALS got broken at some
point - here's a fix:
Index: ext/standard/array.c
===
--- ext/standard/array.c(revision 305556)
+++ ext/standard/array.c(working copy)
@@ -1389,10
Derick, do you make available the scripts used to generate timezonedb.h?
Are you using the location co-ordinates from zone.tab in the "Olson"
database? The data seems to mostly match up, though I noticed that the
data shipped by PHP has Europe/London at:
lat 51.50833 long 0.12527
whereas th
The result of calling getTimezone() on a Date object results in a
DateTimeZone object with a reference to the dateobj->time->tz_info
object which may get later destroyed.
This can cause unexpected script behaviour or interpreter crashes, test
case in attachment (1).
When I fixed this the obvio
When php_stream_cast is passed any of the _AS_FD-like options, what is
the ret argument supposed to point to? This does not seem to be decided
consistently; from a quick survey:
ext/openssl/xp_ssl.c:
php_openssl_sockop_cast() presumes that *ret has sizeof(void *)
ext/soap/php_http.c:
st
On Fri, Jan 11, 2008 at 09:59:46AM +0100, Derick Rethans wrote:
> On Thu, 10 Jan 2008, Joe Orton wrote:
> > On Wed, Jan 09, 2008 at 09:03:02PM +0100, Derick Rethans wrote:
> > > It's not used (anymore). However, there is a PHP function
> > > timezone_iden
Thanks for all the feedback.
On Wed, Jan 09, 2008 at 09:03:02PM +0100, Derick Rethans wrote:
> On Wed, 9 Jan 2008, Joe Orton wrote:
>
> > It's a bit of a maintenance headache for distributions when
> > packages include their own copy of the timezone database, since this
Hi folks. It's a bit of a maintenance headache for distributions when
packages include their own copy of the timezone database, since this
needs to be updated frequently.
I've prepared a patch to allow the timelib code to use the system
timezone database directly; would something like this be
On Mon, Oct 15, 2007 at 09:26:30AM +0200, Stefan Esser wrote:
> Hi,
>
> please keep in mind that compiling PHP with large file support breaks
> binary compatibility...
> One of the globals contain a "stat" struct that has different size for
> LFS or no LFS.
More harmfully, it also changes the ABI
Hi, I'm looking through the list of security issues listed in the 5.2.1
release notes; trying to work out what the impact of these issues is so
we're able to explain to our users how they are affected.
Could anyone help clarify a few of the items listed?
- Fixed allocation bugs caused by attemp
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?
Regards,
joe
--
PHP Internals - PHP Runtime Dev
On Thu, Aug 03, 2006 at 10:19:38AM +0200, Derick Rethans wrote:
...
> Release Announcement: http://www.php.net/release_4_4_3.php
substr_compare() is not in 4.4.x so:
"Fixed offset/length parameter validation inside the substr_compare()
function."
should not be listed here.
Regards,
joe
--
On Thu, Jul 28, 2005 at 03:46:09PM +0530, Kamesh Jayachandran wrote:
> In file included from
> /root/kamesh/work/php-src/ext/pdo_sqlite/pdo_sqlite.c:31:
> /root/kamesh/work/php-src/ext/pdo_sqlite/php_pdo_sqlite_int.h:24:21:
> sqlite3.h: No such file or directory
Same here with VPATH builds, this s
We're getting a lot of reports from Fedora Core 4 users that the shipped
PHP 5.0.4 is triggering some refcounting bug breaking some common apps;
the attached file is a repro case which triggers the segfault after
following the link.
I've traced this through and it seems that the refcount on
PS
this is purely on us and a handful of distribution
> maintainers with minimal cost to the end users, then I think the choice
> should be simple here. Asking Joe Orton and the various other package
> maintainers from the major distros might be a good idea too.
I think it's fair to say we
o end comment
> "Yuml", NULL, NULL, NULL, NULL, NULL, NULL, NULL,
> NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
> NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
> /* 400 (0x0190)*/
> NULL, NULL, "fnof"
>
> Later Joe Orton fixed the above improp
On Wed, Apr 06, 2005 at 10:03:42AM +0200, Martin Kraemer wrote:
> A colleague noticed that in an upgrade from 4.3.10 to 4.3.11 the
> pear/DB extension was no longer installed. The ChangeLog does not
> mention this. Should it be added to the changelog, and why was it
> dropped? I didn't completely f
On Mon, Apr 04, 2005 at 01:35:37AM -0400, Jon Parise wrote:
> Index: build/build2.mk
> ===
> RCS file: /repository/php-src/build/build2.mk,v
> retrieving revision 1.35
> diff -u -r1.35 build2.mk
> --- build/build2.mk 3 Feb 2005 17:42
Any objections to this patch? mysqli is defining a bunch of global
symbols which it looks like it doesn't need to. Not urgent for 5.0.4.
--- php-5.0.3/ext/mysqli/mysqli_prop.c.mysqliglobal
+++ php-5.0.3/ext/mysqli/mysqli_prop.c
@@ -57,7 +57,7 @@
p = (MYSQL_STMT *)((MY_STMT *)((MYSQLI_RESOURCE *
Found by Dave Jones grepping for memset(,,0)... only applies to the 5.0
branch: either correct it as below or remove the line completely?
Index: zend_execute.c
===
RCS file: /repository/ZendEngine2/zend_execute.c,v
retrieving revision
On Thu, Mar 10, 2005 at 11:23:51AM +0100, Ard Biesheuvel wrote:
> Joe Orton wrote:
> >Testing "length >= LONG_MAX" where length is an int is always false, and
> >gcc gives a warning for it. Perhaps something like this was intended?
> >
>
> On 64-bit it is
Testing "length >= LONG_MAX" where length is an int is always false, and
gcc gives a warning for it. Perhaps something like this was intended?
Index: ext/exif/exif.c
===
RCS file: /repository/php-src/ext/exif/exif.c,v
retrieving revi
If struct _zend_arg_info is an incomplete type, the declarations in
zend_modules.h like:
extern struct _zend_arg_info first_arg_force_ref[2];
are not valid C code (it doesn't make sense to declare an array if the
compiler does not know what size each element is, so this is not hard to
understand)
On Thu, Feb 17, 2005 at 07:19:46AM -0500, Rob Richards wrote:
> It looks like there would be BC breaks unless libxml with the bug fix is
> used as the encoding is detected properly and no infinite loop if an xml
> declaration or BOM is used in the xml. So basically with the patch there
> is no m
libxml2's charset encoding auto-detection mode is broken with the push
parser in current versions of libxml2, I found that recently:
http://bugzilla.gnome.org/show_bug.cgi?id=162613
but trying to force it can trigger infinite loops in libxml2, which is
what happens in http://bugs.php.net/?id=3200
On Mon, Feb 14, 2005 at 01:28:26PM -0500, Hans Zaunere wrote:
> Not if you only have 64bit libs installed, which is dangerous, since
> otherwise it doesn't give any warnings and you're not getting what you
> think you are.
You did have some "-L/usr/lib "'s sneak in from somewhere in the make
outp
On Thu, Feb 10, 2005 at 03:21:45PM +0200, Jani Taskinen wrote:
>
> While this patch works fine, what if you don't actually have
> GD installed in your PHP? There should be a configure macro
> that adds the headers when really needed..
Good point. OK, how about this instead:
Index: sc
We had a request to install the ext/gd headers, which are needed to
compile the pdflib extension. Any objections? I've tested this to at
least build the PECL pdflib module.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145891
Index: scripts/Makefile.frag
=
On Mon, Feb 07, 2005 at 10:09:29AM -0500, Hans Zaunere wrote:
>
> > > However, after downloading the php5-200502052330.tar.gz snapshot,
> > > things seem broken again. My ./configure starts out like this:
> > >
> > > ./configure --with-libdir=lib64 --prefix=/usr/local/php --with-
> > apxs=/usr/lo
On Sat, Feb 05, 2005 at 07:03:52PM -0500, Hans Zaunere wrote:
...
> However, after downloading the php5-200502052330.tar.gz snapshot,
> things seem broken again. My ./configure starts out like this:
>
> ./configure --with-libdir=lib64 --prefix=/usr/local/php
> --with-apxs=/usr/local/apache/bin/a
On Tue, Jan 25, 2005 at 03:41:40AM +0200, Jani Taskinen wrote:
> Just commit..
I don't have Zend commit access, can someone do it for me?
> On Mon, 24 Jan 2005, Joe Orton wrote:
>
> >[ping]
> >
> >New versions of glibc support a RTLD_DEEPBIND flag to dlopen.
[ping]
New versions of glibc support a RTLD_DEEPBIND flag to dlopen. The
effect of this flag when loading a "foo.so" with undefined symbols is
that the search that symbol starts at foo.so and its dependencies
*before* the loading process' global symbol table.
This is an effective workaround for
New versions of glibc support a RTLD_DEEPBIND flag to dlopen. The
effect of this flag when loading a "foo.so" with undefined symbols is
that the search that symbol starts at foo.so and its dependencies
*before* the loading process' global symbol table.
This is an effective workaround for symbol n
On Thu, Jan 06, 2005 at 09:49:49PM +0100, Magnus MÃÃttà wrote:
> Hi,
>
> This patch adds apache uptime to phpinfo() page for apache,
> apache2filter and apache2handler SAPIs.
>
> Should I commit, throw it away, change something ?
I don't think there's any need to duplicate more of mod_status in
On Sun, Dec 12, 2004 at 02:56:25PM -0800, Hans Zaunere wrote:
> Some more interesting things that threw me off at first. While 4.3.10
> and 5.0.3 do handle lib64 much better than previous versions, and will
> compile with the basic extensions enabled on a lib64 only system, only
> HEAD really impl
On Sun, Dec 12, 2004 at 11:17:05AM -0500, Wez Furlong wrote:
> Committed, complete with configure checks.
This doesn't seem to compile:
ext/standard/streamsfuncs.c: In function `zif_stream_socket_pair':
ext/standard/streamsfuncs.c:61: error: too few arguments to function
`php_socket_strerror'
ex
On Sun, Sep 12, 2004 at 06:35:51AM -, Antony Dovgal wrote:
> tony2001 Sun Sep 12 02:35:51 2004 EDT
>
> Modified files:
> /php-src acinclude.m4
> Log:
> add PHP_CHECK_64BIT macro to be able to detect 64-bit platform in
> ./configure
>
...
> +dnl PHP_CH
On Fri, Nov 05, 2004 at 11:07:53AM +0100, Derick Rethans wrote:
> On Fri, 5 Nov 2004, Klaus Reimer wrote:
>
> > Marcus Boerger wrote:
> > > we've haered of it in the past but it was too late to add for 4.3
> > > series and obviously nobody cared to look for it for 5.0. So no the
> > > next versi
Setting $REPORT_EXIT_STATUS no longer makes "make test" fail if any
tests fail; is that deliberate or can it be fixed?
Index: Makefile.global
===
RCS file: /repository/php-src/Makefile.global,v
retrieving revision 1.51
diff -u -r1.51
I've committed the core changes to add --with-libdir and updated most of
the extensions which I could test here.
Hans, can you test out HEAD on your SLES box? You should just use
--with-libdir=lib64 and then e.g. --with-mysql=/usr will correctly pick
up the system MySQL libraries in /usr/lib64.
On Tue, Nov 02, 2004 at 01:56:03PM +0100, Derick Rethans wrote:
> On Tue, 2 Nov 2004, Joe Orton wrote:
>
> > HEAD/ext/spl is generating a warning at startup though it was hard to
> > work out which extension was to blame without the below patch!
> >
> > PHP Warning
On Mon, Nov 01, 2004 at 11:16:27AM +0100, Marcus Boerger wrote:
> Hello Sebastian,
>
> Monday, November 1, 2004, 10:43:50 AM, you wrote:
>
> > PHP Warning: Function registration failed - duplicate name -
> > next in Unknown on line 0
>
> how about providing the backtrace when you set a break
HEAD/ext/spl is generating a warning at startup though it was hard to
work out which extension was to blame without the below patch!
PHP Warning: Function registration failed - duplicate name -
InfiniteIterator::next in Unknown on line 0
Index: Zend/zend_API.c
On Sun, Oct 31, 2004 at 01:18:49PM -0800, Hans Zaunere wrote:
> Has anything been committed yet? I'd like to test some things out once
> it has...
No, sorry, not yet. Since it seems nobody has any objections I will
commit the changes to HEAD later this week.
joe
--
PHP Internals - PHP Runtime
On Fri, Oct 22, 2004 at 02:36:00PM +0200, Derick Rethans wrote:
> AFAIK Joe is going to commit his patch, but we need to "fix" it for the
> PECL extensions too if applicable.
I was kind of waiting for Sascha to review it... do you want me to
commit it now? PECL extensions (or any autoconf code in
On Fri, Oct 22, 2004 at 09:49:55AM -0400, Ilia Alshanetsky wrote:
> Joe Orton wrote:
> >Then consider this your official wake-up call :)
>
> LOL. I use Apache 1.3 and found it to work way better then 2.0. 2.0 does
> not offer any useful improvements over the 1.3 base,
On Fri, Oct 22, 2004 at 02:26:50PM +0200, Edin Kadribasic wrote:
> On Friday 22 October 2004 13:33, Joe Orton wrote:
> > On Fri, Oct 22, 2004 at 12:59:04PM +0200, Edin Kadribasic wrote:
> > > However I consider crashing apache children with signal 25 when doing
> > > sim
On Fri, Oct 22, 2004 at 12:59:04PM +0200, Edin Kadribasic wrote:
> However I consider crashing apache children with signal 25 when doing simple
> is_file() or fopen() on large files really harmful. Apache flat out refuses
> to start if you have enabled php error log and that file happen to be 2GB
On Fri, Oct 22, 2004 at 10:53:25AM +0100, Wez Furlong wrote:
> On Fri, 22 Oct 2004 10:45:08 +0100, Joe Orton <[EMAIL PROTECTED]> wrote:
> > On Fri, Oct 22, 2004 at 09:53:14AM +0100, Wez Furlong wrote:
> > > What I planned to do with the streams API for 5.1 was define
> &
On Fri, Oct 22, 2004 at 09:53:14AM +0100, Wez Furlong wrote:
> What I planned to do with the streams API for 5.1 was define
> php_stream_off_t to be a 64-bit type (regardless of LFS support),
> adjust the API where it is needed, and handle the LFS stuff centrally,
> using the transitional LFS funct
There are serious problems from enabling LFS support like this in a
project like PHP.
If I have some library which uses off_t in its API, e.g. zlib, and I
happened to not compile it with LFS support, e.g. as in most Linux
distributions, I now *cannot* call the zlib functions using off_t from
PHP,
On Wed, Oct 13, 2004 at 05:12:22PM +0200, Sascha Schumann wrote:
> On Wed, 13 Oct 2004, Joe Orton wrote:
> >So other than vague slurs on OS sanity, are there objections to
> >committing my --with-libdir patch to HEAD?
>
> I will look at it later.
Have you had a chance
We've just been looking at the security issues which were silently fixed
in 4.3.9/5.0.2. The fixes for array index handling appear to be
incomplete, there is now a segfault for a variable like "?foo[][="
That was just filed as #30442, patch below fixes it.
Also, query strings like: "?foo[[[h
On Wed, Oct 13, 2004 at 09:55:15AM +0200, Sascha Schumann wrote:
> >Going back to 64bit platforms, this is going to be a problem moving
> >forward. AMD64 is all over the place, and thus having lib and lib64
>
> That is hardly a new issue. Irix and other systems have had
> different lib d
On Wed, Oct 06, 2004 at 08:56:15AM -0400, Noah Botimer wrote:
> Joe,
>
> This may be crazy, but does it make sense to think of integers in a more
> defined manner? That is, ``integer'' being equivalent to a long, which
> does have a guarantee on size (32-bit)? Also, some kind of long long
> t
On Tue, Oct 05, 2004 at 05:12:36PM -0700, Andi Gutmans wrote:
> At 02:17 PM 10/5/2004 +0200, Edin Kadribasic wrote:
> >On Tuesday 05 October 2004 14:02, Derick Rethans wrote:
> >> On Tue, 5 Oct 2004, Wez Furlong wrote:
> >> > Feels like a major bug to me... this got into a release? :-/
> >>
> >> Ye
On Fri, Sep 24, 2004 at 10:44:34AM -0700, Andi Gutmans wrote:
> This doesn't have anything to do with the tar.gz itself.
> It seems that with MSIE something screws up (for both 5.0.2and 4.3.9).
> Firefox handles it correctly. Do we have a mime types problem?
The servers should be configured to *no
On Mon, Sep 27, 2004 at 08:36:49PM +0200, Derick Rethans wrote:
> On Mon, 27 Sep 2004, Joe Orton wrote:
> > On Mon, Sep 27, 2004 at 10:13:04AM +0200, Derick Rethans wrote:
> > > I think this patch is the way to go for this, but it won't address
> > > issues w
On Thu, Sep 16, 2004 at 06:31:56AM -0700, Rasmus Lerdorf wrote:
> On Thu, 16 Sep 2004, Joe Orton wrote:
>
> > On Thu, Sep 16, 2004 at 12:39:39PM +0200, Sascha Schumann wrote:
> > > The point is that the current behaviour needs to be retained
> > > fo
On Thu, Sep 16, 2004 at 12:39:39PM +0200, Sascha Schumann wrote:
> The point is that the current behaviour needs to be retained
> for installations which would be negatively affected by your
> patch. Building non-PIC as default is ok, if a switch is
> provided to build PIC.
Ah, go
On Thu, Sep 16, 2004 at 11:53:40AM +0200, Sascha Schumann wrote:
> On Thu, 16 Sep 2004, Joe Orton wrote:
> >This is Rasmus' patch but only enabled on platforms where it's known to
> >work. Applies to HEAD: the apache2handler SAPI builds and loads a
> >shared exten
This is Rasmus' patch but only enabled on platforms where it's known to
work. Applies to HEAD: the apache2handler SAPI builds and loads a
shared extension OK like this on Linux/i686. It looks like some people
preferred a configure flag for this and some preferred to do it by
default. Consensus?
On Sat, Sep 11, 2004 at 03:22:27PM +0200, Ard Biesheuvel wrote:
> Joe Orton wrote:
> >GCC on IA64 does wierd things with this macro, though I think there's a
> >GCC bug involved there too. This fixes the macro to have well-defined
> >behaviour for all values of 'd&
On Tue, Aug 31, 2004 at 09:48:47PM -0700, Andi Gutmans wrote:
> It does look as if you're right. I don't quite understand why the standard
> was written in such a way and not in a way which only makes the value
> itself undefined.
> I think we can apply the patch. Does anyone have a problem with
On Wed, Sep 08, 2004 at 01:05:37PM +0200, Derick Rethans wrote:
> On Wed, 8 Sep 2004, Joe Orton wrote:
>
> > > Didn't Joe mean that it's wrong on Linux/x86_64 or am I misinterpreting his
> > > email?
> >
> > Yup I did mean that. Linux/x86_64 is an
On Tue, Sep 07, 2004 at 11:34:50AM -0700, Andi Gutmans wrote:
> At 10:04 AM 9/6/2004 -0700, Rasmus Lerdorf wrote:
> >On Mon, 6 Sep 2004, Joe Orton wrote:
> >
> >> On Sun, Sep 05, 2004 at 04:41:44PM -0700, Rasmus Lerdorf wrote:
> >> > On Sun, 5 Sep 2004, Andi Gut
On Sun, Sep 05, 2004 at 04:41:44PM -0700, Rasmus Lerdorf wrote:
> On Sun, 5 Sep 2004, Andi Gutmans wrote:
> > Yeah I know non-pic doesn't work on all platforms but I gathered that
> > -prefer-non-pic only uses PIC on platforms where non-PIC dso's aren't
> > supported. I guess I'm wrong and we do ne
On Tue, Aug 17, 2004 at 12:54:55PM -0700, Andi Gutmans wrote:
> Hi agree with Joe on this one. I think it would be beneficial to include
> this patch *even* if it means that we might have to update it from time to
> time. I'm sure Joe will lend a helping hand to do so.
So, am I OK to commit this
On Tue, Aug 31, 2004 at 12:02:31PM +0200, Derick Rethans wrote:
> On Tue, 31 Aug 2004, Joe Orton wrote:
>
> > On Tue, Aug 31, 2004 at 11:47:06AM +0200, Derick Rethans wrote:
> > > On Tue, 31 Aug 2004, Joe Orton wrote:
> > >
> > > > Also, the bug27354 t
On Tue, Aug 31, 2004 at 11:47:06AM +0200, Derick Rethans wrote:
> On Tue, 31 Aug 2004, Joe Orton wrote:
>
> > Also, the bug27354 test needs to be updated since it relies on
> > particular behaviour of integers greater than LONG_MAX on 32-bit
> > platforms; since it look
gcc 3.4.x on x86 optimises the configure test for whether rounding
"fuzz" is needed such that the test result flips from true to false,
unlike previous gcc releases. The bug24142.t tests for PHP round() then
fails, so I presume this is a real problem.
Out-of-line-ing the code a little works aroun
Also, the bug27354 test needs to be updated since it relies on
particular behaviour of integers greater than LONG_MAX on 32-bit
platforms; since it looks like it is only really checking for
not-a-division-by-zero-trap, this seems OK:
--- php-4.3.8/tests/lang/bug27354.phpt.dval2lval
+++ php-4.3.8/t
On Mon, Aug 30, 2004 at 04:40:13PM -0700, Andi Gutmans wrote:
> At 11:17 PM 8/30/2004 +0100, Joe Orton wrote:
> >On Mon, Aug 30, 2004 at 02:20:42PM -0700, Andi Gutmans wrote:
> >> I know it's undefined but why is defining it to LONG_MAX/LONG_MIN any
> >> better? It&
On Mon, Aug 30, 2004 at 02:20:42PM -0700, Andi Gutmans wrote:
> I know it's undefined but why is defining it to LONG_MAX/LONG_MIN any
> better? It's not the kind of behavior which I think we should "define".
C code which has undefined behaviour may segfault or suffer some other
run-time exception
On Mon, Aug 30, 2004 at 12:32:59PM -0700, Andi Gutmans wrote:
> Hi Joe,
>
> It seems like your patch doesn't really fix anything. How is rounding to
> LONG_MAX/LONG_MIN any better?
The C standard says that when converting a double to a long, if the
integral part of the double is outside the rang
The DVAL_TO_LVAL macro is quite weird, I'm not sure exactly what it's
supposed to be doing but it probably isn't doing it. If the integral
part of d is outside the range of a long, the conversion has undefined
behaviour by the C99 standard; an explicit cast makes no difference
AFAICT.
GCC on IA64
#x27;:
Zend/zend_compile.c:71: warning: cast from pointer to integer of different size
> On August 24, 2004 10:53 am, Joe Orton wrote:
> > If casting pointers to integers at least cast to a long, to avoid
> > compiler warnings:
> >
> > --- Zend/zend_compile.c 23 Aug 2004
If casting pointers to integers at least cast to a long, to avoid
compiler warnings:
--- Zend/zend_compile.c 23 Aug 2004 20:58:48 - 1.581
+++ Zend/zend_compile.c 24 Aug 2004 14:50:31 -
@@ -68,7 +68,7 @@
uint char_pos_len;
char *filename;
- char_pos_len = zend_s
On Mon, Aug 23, 2004 at 11:01:38AM +0200, Derick Rethans wrote:
> Committed, thanks!
Thanks. #27791 can be closed now.
joe
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, Aug 23, 2004 at 09:48:06AM +0200, Derick Rethans wrote:
> On Mon, 23 Aug 2004, Joe Orton wrote:
>
> > This fixes the 2.0 SAPI build against HEAD of httpd-2.0:
>
> Can you please send it as an attachment (extension .txt), otherwise it
> get's garbled when
This fixes the 2.0 SAPI build against HEAD of httpd-2.0:
1. pick up correct names for ap[ru]-config from apxs
2. pick up --cppflags etc from apr-config to ensure that
-D_LARGEFILE64_SOURCE is used where necessary (that's bug #27761)
since APR now has large file support
(tested to not break the bu
On Mon, Aug 09, 2004 at 09:46:21AM +0200, Edin Kadribasic wrote:
> I'm -1 on this patch. The problem is has existed for mysql lib for ages and
> for all other libraries used by PHP. A note in the documentation stating that
> if you want to use GD from PHP and another Apache module you need to com
On Fri, Aug 13, 2004 at 11:46:46AM +0100, Joe Orton wrote:
> This fixes the apache2handler build against HEAD of httpd-2.0:
Actually, this alternative patch is a fractionally safer change,
avoiding picking up --cflags from apr-config:
Index: sapi/apache2handler/config
This fixes the apache2handler build against HEAD of httpd-2.0:
1. pick up correct names for ap[ru]-config from apxs
2. pick up --cppflags etc from apr-config to ensure that
-D_LARGEFILE64_SOURCE is used where necessary (that's bug #27761)
since APR now has large file support
(tested to not break
On Mon, Aug 09, 2004 at 09:46:21AM +0200, Edin Kadribasic wrote:
> On Monday 09 August 2004 09:00, Derick Rethans wrote:
> > On Sat, 7 Aug 2004, Joe Orton wrote:
> > > That would mean adding exactly the reverse set of #defines to allow the
> > > the GD extension to b
On Mon, Aug 02, 2004 at 10:55:27AM +0200, Derick Rethans wrote:
> On Fri, 23 Jul 2004, Joe Orton wrote:
>
> > Building the bundled libgd library into PHP causes symbol namespace
> > pollution; if any other Apache modules link a different version of libgd
> > into the
[resend, though I notice gd just got updated with some new functions so
the symbol list is out of date. Feedback welcome on the principal of
the change, anyway]
Building the bundled libgd library into PHP causes symbol namespace
pollution; if any other Apache modules link a different version of l
[resend]
There's no reason why gettimeofday() shouldn''t return the same time in
successive calls; this test fails spuriously on Linux/x86_64 (which has
a particularly fast gettimeofday() implementation).
--- ext/standard/tests/time/001.phpt23 May 2003 20:56:33 - 1.4.2.2
+++ ext/stan
On Mon, Jul 19, 2004 at 01:20:26PM -0700, Jeff Stern wrote:
> libtool: link: `ext/libxml/libxml.lo' is not a valid libtool object
> make: *** [sapi/cgi/php] Error 1
> error: Bad exit status from /var/tmp/rpm-tmp.29174 (%build)
IIRC this is the error you get from trying to build PHP using libtool
1
I think this file needs to be renamed; the 5.0.0 build fails using
mbregex and pcre with bundled pcre, for instance, since the bundled pcre
picks up the wrong php_compat.h and the #define pcre_* aren't picked up.
Renaming it to php_oniguruma.h and changing the #include fixes the
build.
Index: oni
Index: ext/mbstring/config.m4
===
RCS file: /repository/php-src/ext/mbstring/config.m4,v
retrieving revision 1.51
diff -u -r1.51 config.m4
--- ext/mbstring/config.m4 10 Jun 2004 14:06:17 - 1.51
+++ ext/mbstring/config.m4
Building the bundled libgd library into PHP causes symbol namespace
pollution; if any other Apache modules link a different version of libgd
into the Apache process they may instead pick up symbols from the PHP
libgd, and segfault randomly. (One of our users saw this when using
mod_perl with Perl:
There's no reason why gettimeofday() shouldn''t return the same time in
successive calls; this test fails spuriously on Linux/x86_64 (which has
a particularly fast gettimeofday() implementation).
--- ext/standard/tests/time/001.phpt23 May 2003 20:56:33 - 1.4.2.2
+++ ext/standard/tests
(applies to 4.3 branch)
--- ext/standard/tests/strings/strip_tags.phpt 27 Nov 2002 06:20:37 - 1.1.2.1
+++ ext/standard/tests/strings/strip_tags.phpt 14 Jul 2004 11:07:58 -
@@ -17,6 +17,8 @@
echo strip_tags('NEAT STUFF');
echo "\n";
echo strip_tags('TESTS ?!!
[resend, see followup to old thread for patch to HEAD]
It's simpler to just use the ap_r* interfaces in the the handler SAPI
for 2.0, this improves network usage by allowing httpd to buffer as
necessary, and fixes a bug where ub_write is unnecessarily pmemdup'ing
the string (it could have used a t
On Fri, Jun 18, 2004 at 02:13:05PM +0200, Magnus MÃÃttà wrote:
> Hi!
>
> On Friday 18 June 2004 12.30, Joe Orton wrote:
> > It's simpler to just use the ap_r* interfaces in the the handler SAPI
> > for 2.0, this improves network usage by allowing httpd to buffer as
>
It's simpler to just use the ap_r* interfaces in the the handler SAPI
for 2.0, this improves network usage by allowing httpd to buffer as
necessary, and fixes a bug where ub_write is unnecessarily pmemdup'ing
the string (it could have used a transient bucket to avoid that; the
apache2filter got thi
[resend]
It's necessary to pick up EXTRA_CFLAGS and friends when building against
httpd-2.0 HEAD due to LFS support in APR.
Index: sapi/apache2handler/config.m4
===
RCS file: /repository/php-src/sapi/apache2handler/config.m4,v
retrie
On Fri, Apr 23, 2004 at 04:59:27PM +0300, Andi Gutmans wrote:
> If at all, I think this should be fixed in PHP so that it affects all SAPIs
> (i.e. first time we set umask() save the old one and a flag that let's
> RSHUTDOWN know it should change it back).
(In case it wasn't clear, all my patch
It's necessary to pick up EXTRA_CFLAGS and friends when building against
httpd-2.0 HEAD due to LFS support in APR.
Index: sapi/apache2handler/config.m4
===
RCS file: /repository/php-src/sapi/apache2handler/config.m4,v
retrieving revis
1 - 100 of 119 matches
Mail list logo
