Hey,
It seems that VC++ 8.0 (Visual Studio 2005) brings more trouble that its
worth. Mainly the way it deals with the C runtime. After spending hours
and hours of trying to figure out the way to make PHP work under Apache
on Windows and be able to load extensions, I'm throwing in the towel.
I can
(Elizabeth, this is a public follow up to the previous message (shown
below))
Of course, I must not be doing something right, but I was finally able
to compile and successful link by:
1) Adding pcrec_newline.c to the project PCRE source group #3
2) Adding a #include "config.h" to pcre_intern
Hi,
On 1/6/07, Edin Kadribasic <[EMAIL PROTECTED]> wrote:
It seems that VC++ 8.0 (Visual Studio 2005) brings more trouble that its
worth. Mainly the way it deals with the C runtime. After spending hours
and hours of trying to figure out the way to make PHP work under Apache
on Windows and be abl
Edin,
Thanks for the detailed analysis and spending time analyzing the
issue. Based on what you've said I think our best option is to go
back to VC++ 6.0 for this release, we are too far along in the
release cycle to experiment with things. Perhaps for the next release
we can revisit the
This sounds like a sane approach. My own 2c is that your failure to load
represents a failure to correctly package the .manifest data of the
individual modules; perhaps this is due to the individual modules requiring
an entry for php5ts.dll? Without digging deeper, it is probably most sane
to shi
Edin Kadribasic wrote:
>
> I can get PHP to work fine on the command line, both cgi and cli. It
> also works fine under IIS using fastcgi. But loading sapi dll into a
> webserver (not using php.exe or php-cgi.exe) works for the sapi itself,
> but trying to load any extensions via php.ini fails mis
Hello Ilia,
weel 2002 aka 7.0 or 2003 aka 7.1 are pretty fine. We have left behind
6.0 long ago :-)
best regards
marcus
Saturday, January 6, 2007, 5:44:55 AM, you wrote:
> Edin,
> Thanks for the detailed analysis and spending time analyzing the
> issue. Based on what you've said I think ou
From what I know Edin uses VC++ 6.0 which works just fine for our
needs. So, I see no reason to move away from that unless someone can
present a really good reason why it should be done.
On 6-Jan-07, at 2:48 PM, Marcus Boerger wrote:
Hello Ilia,
weel 2002 aka 7.0 or 2003 aka 7.1 are pre
Marcus Boerger wrote:
> Hello Ilia,
>
> weel 2002 aka 7.0 or 2003 aka 7.1 are pretty fine. We have left behind
> 6.0 long ago :-)
For reference, ActiveState python is built on Studio 2003 al la 7.1, while
their perl is still built VC 6, if you are looking to coexist more peacefully
with one or
William A. Rowe, Jr. wrote:
> Marcus Boerger wrote:
>> Hello Ilia,
>>
>> weel 2002 aka 7.0 or 2003 aka 7.1 are pretty fine. We have left behind
>> 6.0 long ago :-)
>
> For reference, ActiveState python is built on Studio 2003 al la 7.1, while
> their perl is still built VC 6, if you are looking
8 PM
> To: PHP Internals List
> Subject: [PHP-DEV] Windows build
>
> Hey,
>
> It seems that VC++ 8.0 (Visual Studio 2005) brings more
> trouble that its worth. Mainly the way it deals with the C
> runtime. After spending hours and hours of trying to figure
> out
the build. There probably is some work that needs to be
> done on the 3rd party libs.
>
> Thanks.
>
> Andi
>
>> -Original Message-
>> From: Edin Kadribasic [mailto:[EMAIL PROTECTED]
>> Sent: Friday, January 05, 2007 7:48 PM
>> To: PHP Internals Lis
Hello Edin,
ok, i thought you would use the newer stuff already. Maybe if you have all
withstaticruntime it *could* work. But I happen to have thesekinds of
problems ofwork as well - a lot unfortunatley.
best regards
marcus
Saturday, January 6, 2007, 10:14:17 PM, you wrote:
> William A. Rowe,
Edin Kadribasic wrote:
> Hi Andi,
>
> Turns out the problem is that Apache is building their binaries using
> VC6 so wrong CRT gets loaded. The only solution I found was to tell
> Windows to load Apache with msvcr80.dll instead of msvcr.dll by suppling
> a manifest file in Apache bin directory. If
> A last interesting question; what sort of headaches have you hit loading
> within the ISAPI/IIS environment? I would presume that older/modern IIS
> flavors suffer from similar headaches?
Seems that the least headache solution is to ship binaries built with
VC6. I have not encountered any probl
My CPU is still smoking in the corner, but it did manage to produce 57MB
of compressed goodies for your download pleasure:
The standard thread-safe build
==
http://downloads.php.net/edink/5.2.1RC2-VC6/php-5.2.1RC2-Win32.zip
(fbd2258728d6aafd139bd693c2dac138)
http://dow
IL PROTECTED]
> Sent: Saturday, January 06, 2007 1:28 PM
> To: Andi Gutmans
> Cc: 'PHP Internals List'
> Subject: Re: [PHP-DEV] Windows build
>
> Hi Andi,
>
> Turns out the problem is that Apache is building their binaries using
> VC6 so wrong CRT gets loaded
L PROTECTED]
> Sent: Saturday, January 06, 2007 6:20 PM
> To: 'Edin Kadribasic'
> Cc: 'PHP Internals List'
> Subject: RE: [PHP-DEV] Windows build
>
> Hi Edin,
>
> The 2% surprises me a lot. We got very different results but
> it might be due to
mailto:[EMAIL PROTECTED]
> Sent: Saturday, January 06, 2007 6:20 PM
> To: 'Edin Kadribasic'
> Cc: 'PHP Internals List'
> Subject: RE: [PHP-DEV] Windows build
>
> Hi Edin,
>
> The 2% surprises me a lot. We got very different results but
> it might be du
Andi Gutmans
Cc: 'PHP Internals List'
Subject: Re: [PHP-DEV] Windows build
Hi Andi,
Turns out the problem is that Apache is building their binaries using
VC6 so wrong CRT gets loaded. The only solution I found was
to tell Windows to load Apache with msvcr80.dll instead of
msvcr.dll by su
Saturday, January 06, 2007 6:20 PM
> > To: 'Edin Kadribasic'
> > Cc: 'PHP Internals List'
> > Subject: RE: [PHP-DEV] Windows build
> >
> > Hi Edin,
> >
> > The 2% surprises me a lot. We got very different results but
> > it might
ssage-
>> > From: Andi Gutmans [mailto:[EMAIL PROTECTED]
>> > Sent: Saturday, January 06, 2007 6:20 PM
>> > To: 'Edin Kadribasic'
>> > Cc: 'PHP Internals List'
>> > Subject: RE: [PHP-DEV] Windows build
>> >
>> > Hi
Andi Gutmans wrote:
Btw, today I never recommend running mod_php on Windows and always point
people to CGI or existing FastCGI implementations.
Well a lot of people develop on windows and deploy on Linux with
mod_php. For these people it probably makes more sense using mod_php on
windows sti
Hello,
On 1/7/07, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
Andi Gutmans wrote:
> Btw, today I never recommend running mod_php on Windows and always point
> people to CGI or existing FastCGI implementations.
Well a lot of people develop on windows and deploy on Linux with
mod_php. For these
Thanks.
>
> Andi
>
>> -Original Message-----
>> From: Edin Kadribasic [mailto:[EMAIL PROTECTED]
>> Sent: Friday, January 05, 2007 7:48 PM
>> To: PHP Internals List
>> Subject: [PHP-DEV] Windows build
>>
>> Hey,
>>
>> It seems that VC
significant performance
>> > improvements in VC8. Our tolower() optimization which is significant
>> is only
>> > for VC8, the compiler creates significantly faster code (on par with
>> Intel
>> > C/C++ compiler), and I believe some of the CRT functions like ti
Don't know if any of this will help, but here's what I've been getting
while trying to use VS 2005.
I'm not sure what the difference is between my debug build and the one
Edin released, but when using my own build apache loads everything fine.
Using Apache 2.0.59 for testing. When I change the
Hmm. I know that, in the past, I've had this kind of issue when
trying to distribute modules that use the debug version of the CRT
(which is itself not redistributable). I wonder if that is sneaking
into the build somehow?
--Wez.
On 1/7/07, Rob Richards <[EMAIL PROTECTED]> wrote:
Don't know i
Well a lot of people develop on windows and deploy on Linux with
mod_php. For these people it probably makes more sense using mod_php on
windows still.
How it should matter for them - PHP is not supposed to be dependant on
SAPI except for maybe some things in environment variables - which woul
Stanislav Malyshev wrote:
> How it should matter for them - PHP is not supposed to be dependant on
> SAPI except for maybe some things in environment variables - which would
> be different on deployment machine anyway?
Not that people should write it like that, but I have seen code in the
wild tha
Not that people should write it like that, but I have seen code in the
wild that uses getallheaders() (Apache only function) to get request
headers instead of using more portable ways.
Oh, I see. If people use Apache-only functions then surely they have to
have Apache :) But since there's a por
Not to drag this thread on any longer, but I think I found the issue.
There is something wrong with Edin's build. A few of the modules do not
have the manifest embedded. I was using bz2 and pdo for testing because
I found that both php_bz2.dll and php_pdo.dll have no embedded manifest.
When I
On Sun, January 7, 2007 3:34 pm, Stanislav Malyshev wrote:
>> Well a lot of people develop on windows and deploy on Linux with
>> mod_php. For these people it probably makes more sense using mod_php
>> on
>> windows still.
>
> How it should matter for them - PHP is not supposed to be dependant on
>
The big one is the HTTP Authentication (?) because, errr, it would
have to pass the password in cleartext through a process that would be
visible to `ps auxwww` ??? So while it's not technically impossible,
FCGI operates by use of pipes, so any data sent back and forth are not
accessible unles
On 12-Jan-07, at 4:12 PM, Stanislav Malyshev wrote:
That said, if my Production environment is mod_php, I want my dev
environment to be mod_php, because I'd rather not find out the hard
way that it makes some subtle but important difference when I get to
QA/staging.
Well, if you develop on Wi
The $_SERVER vars maybe not quite the same as well when comparing
mod_php and fcgi.
I think the vital ones should be the same, though you indeed might lose
some ones like REMOTE_PORT or REMOTE_ADDR - though I checked in my FCGI
setup they seem to be ok.
--
Stanislav Malyshev, Zend Products E
I don't believe you'd lose REMOTE_ADDR in FCGI setup, at least I have
never seen it be lost. It is fairly important for many applications
and I'd imagine we would've heard it is missing. The ones missing
often are DOCUMENT_ROOT, PHP_SELF not being quite the same, PATH_INFO
missing or differ
Hi,
for the new windows build system, what version of cscript.exe do I need
(I seem to have 5.6 in C:\winnt\system32, which does not recognize
/nologo as an option)?
Thanks,
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
i`m still trying to do my first windows build. recently i stopped on
required files in 'bundle' directory. is there any way to get module
directly from cvs with this directory in it? i tried several methods (cvs
(two aliases at least :]), snaps.php.net) and never seem to get this nice
dir inside. a
Latest patch to php_scandir:
http://cvs.php.net/viewvc.cgi/php-src/main/php_scandir.c?r1=1.12.2.1&r2=1.12.2.1.2.1
Seems to break windows build in two places:
main\php_scandir.c(65) : error C2065: 'MAXPATHLEN' : undeclared identifier
main\php_scandir.c(65) : error C2057: expected constant express
The windows build has been update to use libxml2 .22 and libxslt .15.
New release and debug builds of these can be grabbed from
http://ctindustries.net/libxml/
Rob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
with shiny new win32 build system i want to try to build php from source.
but its not as easy as it looks. this is why i`m asking for some hints, i
hope my questions are not to stupid :)
i follow steps from README.WIN32-BUILD-SYSTEM and man.
You need:
- Windows Scripting Host (cscript.exe)
ch
Stas,
Frank already has a patch for this that should be committed shortly.
On 1-Dec-06, at 2:38 PM, Stanislav Malyshev wrote:
Latest patch to php_scandir:
http://cvs.php.net/viewvc.cgi/php-src/main/php_scandir.c?
r1=1.12.2.1&r2=1.12.2.1.2.1
Seems to break windows build in two places:
main
>
> You also need:
> - bindlib_w32 [http://www.php.net/extra/bindlib_w32.zip]
>
> got it.
> changed configuration to release. tried to build the solution:
>
> d:\dev\php_source\bindlib_w32\nsap_addr.c(37): error C2491: 'isxdigit' :
> definition of dllimport function not allowed
>
> i`ve commente
Can someone with a clean windows build test the changes for the libxml/iconv
linking. I believe it is working, but have so many copies of libxml/libxslt
on my system I cant be 100% sure that it is.
A few things. It currently is exporting all libxml symbols. It looks like
there may be about 200K di
Hi Rob,
I'm using iconv 1.9.1 and I get problems with _libiconv_version it does'nt
seam to be in the lib file.
If I remove this from the exports I can build and link php4dllts.lib and
php_xls.dll without problems but not php_iconv.dll.
I'll try to resolve this.
I also move the @echo off to the
From: Frank M. Kromann
> I'm using iconv 1.9.1 and I get problems with _libiconv_version it does'nt
> seam to be in the lib file.
>
> If I remove this from the exports I can build and link php4dllts.lib and
> php_xls.dll without problems but not php_iconv.dll.
Following up on this as it turned ou
ild\lib\libxslt"
(should be Debug not Release in there)
Nice little discovery for bug #26194
works...!
- Steph
> -Original Message-
> From: Rob Richards [mailto:[EMAIL PROTECTED]
> Sent: 20 November 2003 12:24
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] windows bu
From: Steph
> nb that meant downgrading both libxml2 and iconv here..
I dont think going with the 2.6.x branch for libxml is a good idea yet.
Would like it to be out a while longer before using it for releases. It has
some major changes in it as well as a bunch of new features so probably
better
49 matches
Mail list logo
