Guys, --enable-versioning has always been for those who don't
need shared extensions and who want to run multiple PHP
versions concurrently. It does not need to suit everyone's
needs to be useful.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscrib
Works with everything. (phew!)
You might wanna use long instead of int here, as sizeof(ssize_t) is
supposed to match the native pointer size.
--
Ard
Index: main/config.w32.h
=
Steph wrote:
Works with everything. (phew!)
Are you sure this will work on Win64 ?
I think sizeof(ssize_t) is supposed to match the native pointer size.
--
Ard
Index: main/config.w32.h
===
Ard, hi -
ssize_t was originally defined as ptrdiff_t in config.w32.h, which is itself
defined as int in win32 (in stddef.h). It was then redefined as int in the
fcgi configuration. It was also redefined in gd_jpeg.c (one of the few
win32-affecting places that uses it) prior to any includes:
#i
Jani,
Yes, this happens when I create an RPM, however this is still a bug.
Here is RPM's build process:
1) read spec file and look in /usr/src/redhat/SOURCES for files
necessary to build RPM
2) configure and compile with settings targeted at "/"
3) make install into a temporary directory target
Steph,
Windows - uniquely - uses the definition SSIZE_T (type: INT_PTR) - note
that ssize_t isn't the same thing as SSIZE_T, anywhere - but if I go that
route for ssize_t definition (as I already tried to do) we end up with the
fcgi redefinition to int anyway.
Basically all I'm doing here is goin
> ... except that INT_PTR is 64-bit on Win64, and int is not.
>
yeah, I just found that too :)
This means that php-src is currently correct for all architectures but fcgi
src is not. So what's the best line of attack here?
#ifdef _WIN64
+ # define ssize_t SSIZE_T
# define SIZEOF_SIZE_T 8
# defi
At 17:56 14/11/2003, Sascha Schumann wrote:
Guys, --enable-versioning has always been for those who don't
need shared extensions and who want to run multiple PHP
versions concurrently. It does not need to suit everyone's
needs to be useful.
I agree completely.
Zeev
--
PHP Interna
On Fri, 14 Nov 2003, Sascha Schumann wrote:
>Guys, --enable-versioning has always been for those who don't
>need shared extensions and who want to run multiple PHP
>versions concurrently. It does not need to suit everyone's
>needs to be useful.
I guess I didn't make it clear
> I was merely suggesting ways to make it work, or just get rid of it.
> This has nothing to do with the fact that when --enable-versioning
> is used shared extensions will not work. It was just one issue with it.
Either it is working as expected (symbols are not exported;
shar
On Fri, 14 Nov 2003, Sascha Schumann wrote:
>> I was merely suggesting ways to make it work, or just get rid of it.
>> This has nothing to do with the fact that when --enable-versioning
>> is used shared extensions will not work. It was just one issue with it.
>
>Either it is worki
Steph wrote:
... except that INT_PTR is 64-bit on Win64, and int is not.
yeah, I just found that too :)
This means that php-src is currently correct for all architectures but fcgi
src is not. So what's the best line of attack here?
What about
#define ssize_t INT_PTR
for Win{32|64} ??
--
Ard
-
> What about
>
> #define ssize_t INT_PTR
>
> for Win{32|64} ??
>
> --
> Ard
SSIZE_T is already an INT_PTR in both architectures. Calling it INT_PTR
directly, doesn't actually change anything from the current php-src (the
patch Edin put in for me yesterday). The objection Wez made to that was
th
I need the access to the CVS for few php-programmers from different countries.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello Jani,
Friday, November 14, 2003, 5:15:39 PM, you wrote:
> On Fri, 14 Nov 2003, Sascha Schumann wrote:
>>> I was merely suggesting ways to make it work, or just get rid of it.
>>> This has nothing to do with the fact that when --enable-versioning
>>> is used shared extensions wi
Hi Folks:
I'm sorry to be a nudge, but am surprised no one has replied to my prior
post. Perhaps someone is doing some testing or research before replying?
Perhaps it got overlooked? Perhaps everyone is busy and thought someone
else would answer?
Regardless, it would be great if someone could
I'll try and take a look at it next week (I had no time this week).
The problem is that there where bugs in the past when returning by
reference not variables, which could cause memory corruptions. This is why
we didn't allow it. In order not to completely break every script in some
cases we can
To help in the spanish translation of the documentation
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Andi:
On Fri, Nov 14, 2003 at 10:24:45PM +0200, Andi Gutmans wrote:
> I'll try and take a look at it next week (I had no time this week).
Understandable. Thanks for the update.
> The problem is that there where bugs in the past when returning by
> reference not variables, which could cause
Hello Again:
Pardon the followup to myself...
On Fri, Nov 14, 2003 at 05:51:12PM -0500, Daniel Convissor wrote:
> Though, it seems the behavior should be consistent -- sometimes I'm too
> logical :) -- so returning a variable is okay and the rest of it should be
> blocked, OR rework the system s
Forgive me if this is the wrong place to ask, but I'd like to be able to run
both the latest version of the 4.3.x branch and the 5.0.x branch
simultaneously, differentiating only by extension (.php vs. .php5). I am running
Windows XP
Professional and Apache 1.3, and would like to be able to do
21 matches
Mail list logo
