You definitely need header files
Andrey
Michel JORDA wrote:
Thanks for your help everybody ! it seems that the "better" way i found
is
cd
phpize
autoconf
./configure
make
make install
assuming that php is installed in the machine. I dont think the src are
needed.
Thanks for your help
Mich
It was suggested I post this here.
In PHP, the character sequence "://" separates the protocol name from
the protocol-specific part of a stream name. Clearly, the intention is
that these stream names are URLs (i.e., URIs that actually provide a
location for the identified resource). However, the
Hey,
I have a ORM wrapper for PDO which I've been working on for
several weeks. Whilst all of my .phpt tests work just
fine on PHP 5.0.4 (or snaps, depends on my mood) with snaps
PDO binaries on WinXP.
As Wez knows, there are issues with OSX/PHP 5.0.x/PDO, so on
Rasmus' advice I went with current C
I would suggest to fix this, as there are still plenty of people using
7.x...
This is only relevant on Windows, autoconf takes care of it on unix
platforms.
I strongly suspect that he is not in fact linking against libpq version
8. Is ONLY PQprepare and PQsendPrepare missing? What about the re
Which version of libpq is required to compile the new pgsql prepare/execute
commands in php 5.1? I'm getting compilation probles with 8.0.0 client lib
where PQprepare() and PQsendPrepare() seem to be missing.
You required the libpq from PostgreSQL 7.4...
All use of those two functions is protected
erm - when was the decision to no longer maintain the .dsp files made?
Did I go to sleep?
- Original Message -
From: "Uwe Schindler" <[EMAIL PROTECTED]>
To: "Jeff Beidler" <[EMAIL PROTECTED]>;
Cc: "Jeff Beidler" <[EMAIL PROTECTED]>
Sent: Tuesday, April 05, 2005 11:38 PM
Subject: Re: [PH
Thanks for your help everybody ! it seems that the "better" way i found
is
cd
phpize
autoconf
./configure
make
make install
assuming that php is installed in the machine. I dont think the src are
needed.
Thanks for your help
Michel
Andrey Hristov <[EMAIL PROTECTED]> wrote:
> Michel JORD
Please bug this.
James Crumpton wrote:
Now, that may in fact be the proper way to handle things... however,
it was very
handy to be able to replace a single node with multiple top level
nodes (what
DocumentFragments are good for in the first place), and then being
able to
further process all tho
After upgrading to 5.0.4, a script of mine that relies on the DocumentFragment
object suddenly started to segfault. Some debugging of the script found the line
that was causing the segfault to be a call to DOMNode::replaceChild(). The
script is complex enough that it's turning out to be rather dif
Shoot, I copied the wrong diff file, here is the correct diff, please ignore
the previous posting.
cvs diff: Diffing ext/odbc
Index: ext/odbc/config.m4
===
RCS file: /repository/php-src/ext/odbc/config.m4,v
retrieving revision 1.55.2
Hi Jeff,
> -Original Message-
> From: Jeff Beidler [mailto:[EMAIL PROTECTED]
> Would you please be so kind as to take a look at the errors
> I'm getting and steer me in the right direction?
The solution for error about SQLITE_NOTADB has passed the mailinglist
before:
http://www.mail-ar
PHP 5 has a new Unix-Like build system. The DSP files are not longer
maintained. To compile you have to configure first and then compile at the
command line. You need Windows Scripting (for JavaScript configure script)
and a Microsoft Compiler to start the configure.js script and then nmake.
At
Ok, done, is this better?
In config.m4 I am doing 2 things.
First, I am using "uname" to get the platform being compiled on, then using
this info to set the appropriate define needed by RDM Server, i.e. LINUX,
SOLARIS, etc.
Secondly, because RDM Server library names changed when 64-bit support
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> The PHP Development Team would like to announce the immediate release of
> PHP 4.3.11 and 5.0.4. These are maintenance releases that in addition
> to fixing over 70 non-critical bugs, address several security issues.
> The addressed se
Hello,
I have been trying to compile PHP 5.0.4 (downloaded fresh today) and have been
following your instructions at
http://www.php.net/manual/en/install.windows.building.php to the letter. I
always end up with the same thing when trying to compile... 3 errors and a
bunch of warnings. I ha
On Tue, 5 Apr 2005, John Higgins wrote:
> Hi all,
> I would like to submit a patch for PHP 4 as well as PHP 5. The patch
> will update PHP's UODBC
> module to work with more recent versions of Birdstep Technology's RDM Server
> product. The files
> affected are ext/odbc/config.m4 & ext/odb
Hi all,
I would like to submit a patch for PHP 4 as well as PHP 5. The patch
will update PHP's UODBC
module to work with more recent versions of Birdstep Technology's RDM Server
product. The files
affected are ext/odbc/config.m4 & ext/odbc/php_odbc.h. Below is the diff
output for the two
Derick Rethans wrote:
I would suggest to fix this, as there are still plenty of people using
7.x...
This is only relevant on Windows, autoconf takes care of it on unix
platforms.
Edin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Tue, 5 Apr 2005, Edin Kadribasic wrote:
> Which version of libpq is required to compile the new pgsql prepare/execute
> commands in php 5.1? I'm getting compilation probles with 8.0.0 client lib
> where PQprepare() and PQsendPrepare() seem to be missing.
I would suggest to fix this, as there a
Which version of libpq is required to compile the new pgsql prepare/execute
commands in php 5.1? I'm getting compilation probles with 8.0.0 client lib
where PQprepare() and PQsendPrepare() seem to be missing.
Edin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: htt
Marcus Boerger wrote:
Hello Andrey,
Tuesday, April 5, 2005, 5:21:17 PM, you wrote:
Stanislav Malyshev wrote:
GB>>call stack, as if the user had inserted the call to the new
GB>>__autoload() before the last closing }.
Too much magic, IMO. All you need to know is the list of functions, you
don't n
Hello Andrey,
Tuesday, April 5, 2005, 5:21:17 PM, you wrote:
> Stanislav Malyshev wrote:
>> GB>>call stack, as if the user had inserted the call to the new
>> GB>>__autoload() before the last closing }.
>>
>> Too much magic, IMO. All you need to know is the list of functions, you
>> don't need
> > It already "blew up" existing applications before this commit.
>
> I'd say that all extensions should really follow the 1 prefix per ext
> for anything that ends up in the global namespace (classes, functions.
> constants ..) rule. Just as we did in the past with new procudural
> extension
Stanislav Malyshev wrote:
GB>>call stack, as if the user had inserted the call to the new
GB>>__autoload() before the last closing }.
Too much magic, IMO. All you need to know is the list of functions, you
don't need any 'stack' since they do not call each one.
Stanislav,
a stack is a list and
On Tue, 5 Apr 2005, Marcus Boerger wrote:
> this happens with any other class/interface we define also. And we've
> discussed that before. The result was that we use the names in c we want
> and try to do the best common implementation possible to keep everybody
> as happy as possible.
>
> Unfor
On Tue, Apr 05, 2005 at 09:20:17AM +0100, Joe Orton wrote:
> 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.
GB>>call stack, as if the user had inserted the call to the new
GB>>__autoload() before the last closing }.
Too much magic, IMO. All you need to know is the list of functions, you
don't need any 'stack' since they do not call each one.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PR
Marcus Boerger wrote:
Hello Greg,
Monday, April 4, 2005, 2:04:47 PM, you wrote:
Andrey Hristov wrote:
Stanislav,
Greg probable means something like a stack trace of the autload callbacks
that were called. This will be a nice addition just like Exception
stacktraces
are (I wish there were stacktra
Hello Jared,
Tuesday, April 5, 2005, 1:58:04 PM, you wrote:
>>
>> I'd say that all extensions should really follow the 1 prefix
>> per ext for anything that ends up in the global namespace
>> (classes, functions.
>> constants ..) rule. Just as we did in the past with new
>> procudural extens
Andi Gutmans wrote:
> I'd like to roll PHP 5.1 Beta 1 very soon.
What about the ability to declare type-hinted parameters as optional?
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
--
PHP
>
> I'd say that all extensions should really follow the 1 prefix
> per ext for anything that ends up in the global namespace
> (classes, functions.
> constants ..) rule. Just as we did in the past with new
> procudural extensions.
>
> This has the advantage of:
> - limiting the number of nam
Sebastian Bergmann wrote:
Andrey Hristov wrote:
isn't this going to blow up existing applications that define class
File?
It already "blew up" existing applications before this commit.
I'd say that all extensions should really follow the 1 prefix per ext
for anything that ends up in the global
Hello Greg,
Monday, April 4, 2005, 2:04:47 PM, you wrote:
> Andrey Hristov wrote:
>> Stanislav,
>> Greg probable means something like a stack trace of the autload callbacks
>> that were called. This will be a nice addition just like Exception
>> stacktraces
>> are (I wish there were stacktraces
Andrey Hristov wrote:
> isn't this going to blow up existing applications that define class
> File?
It already "blew up" existing applications before this commit.
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B
Hi,
the funxtions are stored in the EG(function_table) hash table. So you could
delete or rename the mail function from there and add a new one.
APD has an override_function() and a rename_function() which can be used to
replace/rename a function by a user defined one. Maybe the code of these
he
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
I'd like to create PECL module which could replace mail() function. The new
function would use SMTP protocol. I can't call any external utilities so this
is the only posibility to send the mails. The environment is shared hosting
platform so there are some limits, like forbidding the calling sui
37 matches
Mail list logo
