Is it possible to link php.exe (on Windows) statically, in a way that no DLL
be needed?
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
After a nth discussion on phpdev with Stig, Sebastian and me, I post
this message to ask you the way we should go to solve the problem of
useless constants define in config.w32.h (see bottom).
The main idea is to check if an environment is available and use it. It
will not be too
On Sun, 1 Dec 2002 09:48:35 -0500
Dan Kalowsky [EMAIL PROTECTED] wrote:
Sounds like an interesting idea, but does this:
A) accurately reflect the changes you want to do (I think the #defines
are messed up)
They are here, but useless ;-)
B) work at all on a pre-built binary?
I do not
We could change it to something like this:
#define PEAR_INSTALLDIR
(getenv(PEAR_INSTALLDIR))?getenv(PEAR_INSTALLDIR):c:\\php4\\pear
#define PHP_BINDIR (getenv(PHP_BINDIR))?getenv(PHP_BINDIR):c:\\php4
#define PHP_CONFIG_FILE_PATH
(getenv(PHP_CONFIG_FILE_PATH))?getenv(PHP_CONFIG_FILE_PATH):
#define
On Sun, 01 Dec 2002 07:57:18 -0800
Frank M. Kromann [EMAIL PROTECTED] wrote:
We could change it to something like this:
#define PEAR_INSTALLDIR
(getenv(PEAR_INSTALLDIR))?getenv(PEAR_INSTALLDIR):c:\\php4\\pear
As far as I remember, that s what has been done weeks ago and causes a
compile
Yu are right. Two of the values needs to be constants, as these are used
in building the INI array.
Setting the constants to this works:
#define PEAR_INSTALLDIR
(getenv(PEAR_INSTALLDIR))?getenv(PEAR_INSTALLDIR):c:\\php4\\pear
#define PHP_BINDIR (getenv(PHP_BINDIR))?getenv(PHP_BINDIR):c:\\php4
hi guys,
a few minutes ago i checked in the first more or less working version of
sapi/milter. once compiled the binary can be used as a sendmail milter
plugin and you can process all mails in php. you can even change the
script without having to restart the milter (except the milter_init()
Hello,
I just commited patches to fix CGI running under Apache. This also
fixes issues with incorrect CGI environment variables that are received
under ScriptAlias based CGI or mod_fastcgi. My previous email
describing this is at
http://marc.theaimsgroup.com/?l=php-devm=103834043816376w=2
Hey that looks good,
I believe it won't be in 4.3, isn't it?
Thomas
On Sun, 1 Dec 2002 21:42:29 +0100 [EMAIL PROTECTED] (Harald Radi) wrote:
hi guys,
a few minutes ago i checked in the first more or less working version of
sapi/milter. once compiled the binary can be used as a sendmail
On Sun, 1 Dec 2002, Shane Caraveo wrote:
Hello,
I just commited patches to fix CGI running under Apache. This also
fixes issues with incorrect CGI environment variables that are received
under ScriptAlias based CGI or mod_fastcgi. My previous email
describing this is at
At 07:17 PM 11/30/2002 -0500, Sterling Hughes wrote:
hrm. :)
My only question is really about sequential accesses. for the purpose of
example
let's pretend its just for zvals...
(pool is our pool array of zval structs)
ALLOC_ZVAL()
- Do we have a zval available?
- yes!
-
Hi,
I'm not sure who is in charge of LXR, but would it be possible to make
this tool also parse the extensions available in pear/PECL ? I'm a
struggling newbie in writing PHP extensions and this ability would help a
lot.
Cheers,
Joao
--
PHP Development Mailing List http://www.php.net/
To
Sure,
once LXR moves to a new machine i'll make that work.
Thanks,
James
-Original Message-
From: Joao Prado Maia [mailto:[EMAIL PROTECTED]]
Sent: Sunday, December 01, 2002 11:42 PM
To: [EMAIL PROTECTED]
Subject: [PHP-DEV] LXR on pear/PECL
Hi,
I'm not sure who is in
I get this with PHP_4_3_0 branch (with Linux):
/usr/bin/autoheader: Symbol `size_t' is not covered by
/usr/share/autoconf/acconfig.h ./acconfig.h
And main/php_config.h.in is not created.
(this does not happen with HEAD)
--Jani
--
PHP Development Mailing
On Mon, 2 Dec 2002 04:39:34 +0200 (EET)
Jani Taskinen [EMAIL PROTECTED] wrote:
I get this with PHP_4_3_0 branch (with Linux):
/usr/bin/autoheader: Symbol `size_t' is not covered by
/usr/share/autoconf/acconfig.h ./acconfig.h
I get the same result and this too (in both
Is this just starting? How long since your last configured? I just
added two new m4 files, but they shouldn't get used unless you
--enable-fastcgi, did you do that?
Shane
Magnus Määttä wrote:
On Mon, 2 Dec 2002 04:39:34 +0200 (EET)
Jani Taskinen [EMAIL PROTECTED] wrote:
I get this with
On Sun, 1 Dec 2002, Shane Caraveo wrote:
Is this just starting? How long since your last configured? I just
Not sure when this has started, I just happened to notice it now..
(I usually don't pay attention to the output of buildconf :)
added two new m4 files, but they shouldn't
On Mon, 2 Dec 2002, Jani Taskinen wrote:
I get this with PHP_4_3_0 branch (with Linux):
/usr/bin/autoheader: Symbol `ssize_t' is not covered by
/usr/share/autoconf/acconfig.h ./acconfig.h
And main/php_config.h.in is not created.
(this does not happen with HEAD)
Testing my existing SQL Server based sites with 4.3.0RC2 resulted in
many memory access violations and crashes. I believe that I have
tracked these down to two different changes made to the MSSQL extension
since 4.2.3:
1) In version 1.82 of php_mssql.c there were 6 mallocs that were
changed from
Jani Taskinen wrote:
On Mon, 2 Dec 2002, Jani Taskinen wrote:
I get this with PHP_4_3_0 branch (with Linux):
/usr/bin/autoheader: Symbol `ssize_t' is not covered by /usr/share/autoconf/acconfig.h ./acconfig.h
And main/php_config.h.in is not created.
(this does not happen with
On Sun, 1 Dec 2002, Shane Caraveo wrote:
Jani Taskinen wrote:
On Mon, 2 Dec 2002, Jani Taskinen wrote:
I get this with PHP_4_3_0 branch (with Linux):
/usr/bin/autoheader: Symbol `ssize_t' is not covered by
/usr/share/autoconf/acconfig.h ./acconfig.h
And
On Mon, 2 Dec 2002 05:21:52 +0200 (EET)
Jani Taskinen [EMAIL PROTECTED] wrote:
On Sun, 1 Dec 2002, Shane Caraveo wrote:
Is this just starting? How long since your last configured? I just
Not sure when this has started, I just happened to notice it now..
(I usually don't pay
At 05:27 PM 12/1/2002 -0500, Sterling Hughes wrote:
At 07:17 PM 11/30/2002 -0500, Sterling Hughes wrote:
hrm. :)
My only question is really about sequential accesses. for the purpose of
example
let's pretend its just for zvals...
(pool is our pool array of zval structs)
ALLOC_ZVAL()
Are you sure we should have this stuff in the branch of 4.3? Are these bugs
which didn't exist in 4.2.3?
If they did exist I'm -1. If they didn't exist then that's life and the
patch should stay in but people familiar with CGI should review it carefully.
Andi
At 02:21 AM 12/2/2002 +, Shane
From 4.3 branch with ZE2 i get this compile error:
/bin/sh /opt/DEV/php/php430/php4/libtool --mode=compile gcc -Iext/tokenizer/
-I/opt/DEV/php/php430/php4/ext/tokenizer/ -DPHP_ATOM_INC
-I/opt/DEV/php/php430/php4/include -I/opt/DEV/php/php430/php4/main
-I/opt/DEV/php/php430/php4
It's not a matter of php cgi just having a couple bugs, it was
completely broken. If we don't put it in 4.3, pull the cgi module out
entirely because it's useless. Yet another point of view also, since no
one has seriously complained about it's brokeness, it can't realy effect
many people
Andi fixed it in CVS, try checking out downloading tokenizer.c again.
Magnus Määttä wrote:
From 4.3 branch with ZE2 i get this compile error:
/bin/sh /opt/DEV/php/php430/php4/libtool --mode=compile gcc -Iext/tokenizer/ -I/opt/DEV/php/php430/php4/ext/tokenizer/ -DPHP_ATOM_INC
On Thu, 2002-11-28 at 19:08, Marcus Börger wrote:
At 18:59 28.11.2002, Ilia A. wrote:
On November 28, 2002 12:56 pm, Maxim Maletsky wrote:
Shall we still consider introducing error codes to PHP? IMO, it does not
represent any enormous maintenance increase while has some positive
points.
On Mon, 02 Dec 2002 13:59:08 +0800
Alan Knowles [EMAIL PROTECTED] wrote:
Andi fixed it in CVS, try checking out downloading tokenizer.c again.
Yeah, it compiled now..
But now I get this:
Zend/zend_language_scanner.c:5537: syntax error before int
Zend/zend_language_scanner.c:5772: warning:
There is an impedence mismatch here between typical usage on Unix and
typical usage on Windows. Some infomation that can typically be compiled-in
on Unix must be determined at runtime on Windows.
I don't believe the environment is really a good place to be expecting this
information - not on
30 matches
Mail list logo
