OpenSSH
[Top] [All Lists]

Re: Redefinition of _res in getrrsetbyname.c

To: Curt Sampson <cjs@cynic.net>, openssh-unix-dev@mindrot.org
Subject: Re: Redefinition of _res in getrrsetbyname.c
From: Darren Tucker <dtucker@zip.com.au>
Date: Sat, 24 Mar 2007 23:57:35 +1100
Delivered-to: sp-com-lists@consult.net
Delivered-to: openssh-unix-dev-list1@securepoint.com
Delivered-to: openssh-unix-dev-tmda@mindrot.org
Delivered-to: openssh-unix-dev@mindrot.org
In-reply-to: <Pine.NEB.4.64.0703122056000.10644@homeric.cynic.net>
List-archive: <http://lists.mindrot.org/pipermail/openssh-unix-dev>
List-help: <mailto:openssh-unix-dev-request@mindrot.org?subject=help>
List-id: Development of portable OpenSSH <openssh-unix-dev.mindrot.org>
List-post: <mailto:openssh-unix-dev@mindrot.org>
List-subscribe: <http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev>, <mailto:openssh-unix-dev-request@mindrot.org?subject=subscribe>
List-unsubscribe: <http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev>, <mailto:openssh-unix-dev-request@mindrot.org?subject=unsubscribe>
References: <Pine.NEB.4.64.0703122056000.10644@homeric.cynic.net>
Reply-to: dtucker@zip.com.au
Sender: openssh-unix-dev-bounces+openssh-unix-dev-list1=securepoint.com@mindrot.org
User-agent: Mutt/1.5.11
On Mon, Mar 12, 2007 at 09:06:19PM +0900, Curt Sampson wrote:
> I've been trying to figure out why I can't seem to use SSHFP
> fingerprints delivered via DNSSEC, which led me to try to figure out why
> OpenSSH won't use DNSSEC on my NetBSD-4-branch platform.
> 
> It turns out that around line 70 in openbsd-compat/getrrsetbyname.c, we
> have the following:
> 
>      /* to avoid conflicts where a platform already has _res */
>      #ifdef _res
>      # undef _res
>      #endif
>      #define _res    _compat_res
> 
>      struct __res_state _res;
[...]

We could do this, which also apparently resolves the original problem
that prompted the change above.

Index: configure.ac
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh/configure.ac,v
retrieving revision 1.373
diff -u -p -r1.373 configure.ac
--- configure.ac        21 Mar 2007 10:39:57 -0000      1.373
+++ configure.ac        24 Mar 2007 12:56:43 -0000
@@ -3151,6 +3151,25 @@ int main()
                        [#include <arpa/nameser.h>])
        ])
 
+AC_MSG_CHECKING(if struct __res_state _res is an extern)
+AC_LINK_IFELSE([
+#include <stdio.h>
+#if HAVE_SYS_TYPES_H
+# include <sys/types.h>
+#endif
+#include <netinet/in.h>
+#include <arpa/nameser.h>
+#include <resolv.h>
+extern struct __res_state _res;
+int main() { return 0; }
+               ],
+               [AC_MSG_RESULT(yes)
+                AC_DEFINE(HAVE__RES_EXTERN, 1,
+                   [Define if you have struct __res_state _res as an extern])
+               ],
+               [ AC_MSG_RESULT(no) ]
+)
+
 # Check whether user wants SELinux support
 SELINUX_MSG="no"
 LIBSELINUX=""
Index: openbsd-compat/getrrsetbyname.c
===================================================================
RCS file: 
/usr/local/src/security/openssh/cvs/openssh_cvs/openbsd-compat/getrrsetbyname.c,v
retrieving revision 1.23
diff -u -p -r1.23 getrrsetbyname.c
--- openbsd-compat/getrrsetbyname.c     19 Feb 2007 11:56:56 -0000      1.23
+++ openbsd-compat/getrrsetbyname.c     24 Mar 2007 12:47:47 -0000
@@ -67,13 +67,9 @@ extern int h_errno;
 #endif
 #define _THREAD_PRIVATE(a,b,c) (c)
 
-/* to avoid conflicts where a platform already has _res */
-#ifdef _res
-# undef _res
-#endif
-#define _res   _compat_res
-
+#ifndef HAVE__RES_EXTERN
 struct __res_state _res;
+#endif
 
 /* Necessary functions and macros */
 

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

<Prev in Thread] Current Thread [Next in Thread>