hi, On Wed, Jan 18, 2012 at 6:37 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote: > On 1/18/2012 6:13 AM, Lester Caine wrote: >> >> A much better reason for not supporting the build is probably that the 64bit >> compiler is >> not available in the free development stack? We have to buy a development >> stack to get the >> 64bit compiler which blocks rather than working with the publicly available >> process :( >> But actually that is a better reason for supplying a 64 bit build, and why >> others are >> providing that service. > > Actually, no. There are any number of free mechanisms to build 64 bit code.
None of them are part of what we support tho' (we do not support mingw for example, and won't support it). > The root problem is that Windows "WIN64" is a 64P architecture. Linux and > *nix variants, on the other hand, are 64ILP or 64LP. Meaning Windows has > longs/ints which are undersized compared to the *nix brethren. The old and > stale abuse such as unsigned long X = (unsigned long)pY; will not do what > the author intended. > > This means all packages ported to *nix 64 bits may have very serious flaws > which have not been fixed for *Windows 64 bit* architecture. That's a perfect good example of the numerous issues, and not only in PHP itself but in all dependencies. > I'd anticipate > CoApp identifying and resolving most of these applicable to PHP over the > coming months, but it is a non-trivial problem requiring a number of pairs > of eyeballs to get right. Not going to be supported by PHP any time soon, so I won't hold my breath or put one cent on that tool at this stage (for php, as it is what I can talk about right now). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
