Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:42651 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 93189 invoked from network); 15 Jan 2009 22:30:51 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Jan 2009 22:30:51 -0000 Authentication-Results: pb1.pair.com smtp.mail=wrowe@rowe-clan.net; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=wrowe@rowe-clan.net; sender-id=unknown Received-SPF: error (pb1.pair.com: domain rowe-clan.net from 64.202.165.183 cause and error) X-PHP-List-Original-Sender: wrowe@rowe-clan.net X-Host-Fingerprint: 64.202.165.183 smtpauth03.prod.mesa1.secureserver.net Received: from [64.202.165.183] ([64.202.165.183:56774] helo=smtpauth03.prod.mesa1.secureserver.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7D/76-59137-619BF694 for ; Thu, 15 Jan 2009 17:30:50 -0500 Received: (qmail 30762 invoked from network); 15 Jan 2009 22:30:40 -0000 Received: from unknown (76.252.112.72) by smtpauth03.prod.mesa1.secureserver.net (64.202.165.183) with ESMTP; 15 Jan 2009 22:30:40 -0000 Message-ID: <496FB90F.2010506@rowe-clan.net> Date: Thu, 15 Jan 2009 16:30:39 -0600 User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Pierre Joye CC: Christian Seiler , Stanislav Malyshev , PHP Internals References: <496E65B2.1070106@zend.com> <496F81E0.1090507@gmx.net> <496F88CA.2040007@gmx.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] build IDs proposal From: wrowe@rowe-clan.net ("William A. Rowe, Jr.") Pierre Joye wrote: > > A VC6 extension is not compatible with a VC9 build (or the other way > round). It crashes randomly depending on what the extension does > (xdebug for one is really good for this test :). This is only true for specific combinations of extensions and 3p libs based on what resources the one grabs that the other releases. E.g. if the 3p lib calls malloc and expects the ext to call free(), those two must use the same msvcr. Similarly, an extension that close()'s a file handle allocated by php core, then those two must use the same. For most well partitioned API's this is simply not a problem. (e.g. for mod_perl which is anything but partitioned, it's a horrible situation.) If the additional info were a diagnostic form, that would be nice. As a roadblock to loading an extension? That's a nonstarter. The day after you ship Studio 9 builds (quit saying VC9 already! Studio 6 shipped VC12 a very long time ago) you recognize people will be also building with Studio 10? That's just the way these things go. So +1 for extra information; I can find that with the forever-distributed depends.exe tool anyways, but -1 to some blanket "enforcement" or for building this into the enforced "fingerprint" of php. And +1 for enforcing things such as zts by way of such a fingerprint.