Re: [PHP-DEV] Differences in VC6 and VC9 Windows builds and MSSQL Driver.

hi,

On Fri, Jan 2, 2009 at 11:46 PM, William A. Rowe, Jr.
<[email protected]> wrote:

> Apache mods can be compiled, as you say, using whatever the user wants.
> We have plans to fully support nmake -f makefile.win based on whatever
> compiler tool chain the user wants, including studio 9.  (FWIW VC9 is
> very very ancient, I don't think that's what you meant.  Studio 6 was
> shipping with VC12).

I mean VC9 as in Visual Studio 2k8.

> Sure, should continue those discussions, they've been ongoing for some
> time.  But although the kernel and windows team rejected their approach
> and they still don't see the light, I'm sure we'll convince them straight
> away ;-)

lol :-)

>> We can also help other projects to do the move. Either by providing
>> build/snapshot support or by porting the softwares to VC9 when
>> necessary. I did that already for many projects. They were all pretty
>> happy to get some help, except a couple of projects which do not want
>> to work with any VC version anyway.
>
> If only I got to ignore those ;-P  Nope, I pretty much build everything
> on VC whether the teams want the help or not.  If there is something you
> would like me to help champion to the maintainers of a project that we
> share an interest in, I'm happy to join you in prodding them.

On top of my head comes openldap and smnp.

> I've had these conversations with ActiveState, don't expect things to
> move rapidly for python and perl.  It's rather fits and spurts (I hadn't
> even looked at their very latest builds, too many bugs in the perl 5.10.0
> to even bother worrying it on win32).  Almost certain their last perl
> release for amd64 binds to msvcrt (very forcefully, I might add --- they
> have really made things difficult in source builds to NOT decouple
> msvcrt and to actually use the msvcrXX of the week).

Right, it will take time, especially with perl.

However, having apache and its (core/top) modules available as VC9
could give a kick to other projects.

I wonder if we could do something like what we do now for PHP 5.3+
(http://windows.php.net/snapshots/). What would rock is to work
together on the dependencies (tools or libs). Sharing the same
conventions (names of the libs, paths, etc.) and bins can definitively
help other developers or projects to work on windows or port their
projects to windows (without mingw or cygwin). More at the end of this
mail.

>>> OpenSSL project compiles to msvcrt from the modern compilers.
>>
>> I compile openssl with any VC versions, for the record. It is
>> available in our repository as well.
>
> Of course, and I have no plans to use anyone's repository but OpenSSL's.

I mean the bins, I use their repos for the sources. It works out of
the box except the little bug in the header for VC9 (see
http://wiki.php.net/internals/windows/libs/openssl).

By the way, the libs we use with PHP are available here:

lists+docs: http://wiki.php.net/internals/windows/libs
downloads: http://pecl2.php.net/downloads/php-windows-builds/php-libs/


>> All in all, the problem with CRT is the same than with libc. You can't
>> use an app compiled with a a given libc or any other libraries on
>> unix. However, if we prepare the move well, we can avoid further pains
>> for the next years.
>
> Uhm, what?  I have no problems using glibc 2.3 over a vast number of
> linux revs, nor using solaris libc across three version majors.  You
> are comparing to a tennis court to a football stadium.

Not really, I cannot count the amount of times a system got borked
because of bad libc versions or updates. It is indeed possible to get
something clean and working with many major versions, but not every
libs and apps are clean and work with many versions.

The same applies with the CRTs, it is somehow possible to make a bin
works with any CRT, but the pain to achieve that is not worth the
effort imho.


> Sorry if we disagree on the flavoring of the kool aid, but this stuff
> has bitten me so many times, that I have reasonably little respect left
> for the stupidity that can come from particular teams at MS.

We don't really disagree, I'm simply a bit more optimistic. And we
agree on one thing, these CRTs are painful.


Let try to move one step forward (I would like to argue more about
MSFT stupid choices history but I like even more to get a fast rock
solid wamp stack =).

What do you think about a common team to work on the dependencies and
on a VC9 version of the apache stack? The apachelounge.com developer
could surely be interested as well. If yes, do you have some dedicated
site/pages for your work? I can try to see what we are missing or what
do we have in common already.

Cheers,
-- 
Pierre

http://blog.thepimp.net | http://www.libgd.org