Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:42530 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 20044 invoked from network); 7 Jan 2009 13:04:52 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Jan 2009 13:04:52 -0000 Authentication-Results: pb1.pair.com header.from=scott@macvicar.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=scott@macvicar.net; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain macvicar.net from 193.227.246.108 cause and error) X-PHP-List-Original-Sender: scott@macvicar.net X-Host-Fingerprint: 193.227.246.108 ip246-108-v193.static.x-ip.net Received: from [193.227.246.108] ([193.227.246.108:43979] helo=lovelace.midden.org.uk) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 9A/9D-41481-278A4694 for ; Wed, 07 Jan 2009 08:04:51 -0500 Received: from office.vbulletin.com ([217.155.246.60] helo=[10.0.0.116]) by lovelace.midden.org.uk with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1LKY5S-0008Us-US; Wed, 07 Jan 2009 13:04:47 +0000 Message-ID: <4964A864.9070203@macvicar.net> Date: Wed, 07 Jan 2009 13:04:36 +0000 User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Kalle Sommer Nielsen CC: PHP internals References: <2dedb8a0901062249w16eb644er8426c7db0f197d6d@mail.gmail.com> In-Reply-To: <2dedb8a0901062249w16eb644er8426c7db0f197d6d@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.3 X-Spam_Report: Spam detection software, running on the system "lovelace.midden.org.uk", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi Kalle, Kalle Sommer Nielsen wrote: > Hi Scott > > 2009/1/7 Scott MacVicar : >> I went to look at the bug Pierre mention earlier and noticed that >> dns_get_record isn't implemented on OS X, this looks to be down to the fact >> that it has a bind 8 BC layer that we use by default for some reason. I >> tried to make it use the bind 9 interface but it wasn't a simple task as >> some other things were missing. >> >> End result here is a patch that allows bind 8 to work and therefore OS X, >> the main difference is that there is a shared _res structure rather than a >> per request one. > > Does this mean it will also work on BSD? As far I remember then > dns_get_record wasn't implemented on BSD aswell. If not then it would > be ideal to support it if OSX is patched :) [...] Content analysis details: (-4.3 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.1 AWL AWL: From: address is in the auto white-list Subject: Re: [PHP-DEV] dns_get_record for OSX From: scott@macvicar.net (Scott MacVicar) Hi Kalle, Kalle Sommer Nielsen wrote: > Hi Scott > > 2009/1/7 Scott MacVicar : >> I went to look at the bug Pierre mention earlier and noticed that >> dns_get_record isn't implemented on OS X, this looks to be down to the fact >> that it has a bind 8 BC layer that we use by default for some reason. I >> tried to make it use the bind 9 interface but it wasn't a simple task as >> some other things were missing. >> >> End result here is a patch that allows bind 8 to work and therefore OS X, >> the main difference is that there is a shared _res structure rather than a >> per request one. > > Does this mean it will also work on BSD? As far I remember then > dns_get_record wasn't implemented on BSD aswell. If not then it would > be ideal to support it if OSX is patched :) Yeah it would work on all of the BSDs, though we have some wierd bastardisation of bind8 and bind9 code in dns.c, I think some gentle refactoring is in order to get this in a bit better shape. OS X actually has res_nmkquery but AC_CHECK_FUNC can't correctly detect this because of the way its defined in resolv.h, it's something like this. #define res_nmkquery bind_9_nmkquery AC_CHECK_FUNC does an #undef res_nmkquery as part of its test resulting in the failure. FreeBSD has __res_nmkquery but unfortunately PHP_CHECK_FUNC when checking for res_nmkquery OR __res_nmkquery it doesn't tell you which one it found. I'll fix this in stages I guess, starting with the autoconf fun. Scott