compile problems on Mac OS X (with XCode 1.2 and BIND9)

Hi,

I don't if this is the right list to post this message, but in case someone has the same problem, she can resolve it manually before we fix in in the configure script. (Vern, I can't find project Bro on either Mantis or bugzilla.)

I am trying to compile Bro on a Mac OS X and encounter the following two problems, both related to nb_dns.c:

The first is compile error. It is because the header file arpa/nameser.h does not define HEADER, which is defined in arpa/nameser_compat.h. nameser_compat.h will be included by nameser.h only if BIND_8_COMPAT is defined, but I don't know if we should define that. After including nameser_compat.h in nb_dns.c, it is able to compile correctly.

gcc -I. -Ilibedit -O -c nb_dns.c
nb_dns.c: In function `_nb_dns_mkquery':
nb_dns.c:255: error: syntax error before '*' token
nb_dns.c:306: error: `hp' undeclared (first use in this function)
nb_dns.c:306: error: (Each undeclared identifier is reported only once
nb_dns.c:306: error: for each function it appears in.)
nb_dns.c:306: error: `HEADER' undeclared (first use in this function)
nb_dns.c:306: error: parse error before ')' token
nb_dns.c: In function `nb_dns_host_request2':
nb_dns.c:340: error: `T_A' undeclared (first use in this function)
nb_dns.c:345: error: `T_AAAA' undeclared (first use in this function)
nb_dns.c: In function `nb_dns_addr_request2':
nb_dns.c:412: error: `T_PTR' undeclared (first use in this function)
nb_dns.c: In function `nb_dns_activity':
nb_dns.c:468: error: `HFIXEDSZ' undeclared (first use in this function)
nb_dns.c:576: error: `T_A' undeclared (first use in this function)
nb_dns.c:577: error: `T_AAAA' undeclared (first use in this function)
nb_dns.c:605: error: `T_PTR' undeclared (first use in this function)
make: *** [nb_dns.o] Error 1

Next came the link error:

ld: Undefined symbols:
_res_9_dn_expand
_res_9_init
_res_9_mkquery
_res_9_ns_initparse
_res_9_ns_msg_getflag
_res_9_ns_parserr

This is because libresolv is not linked. Looking at the configure script reveals that it looks for libresolv.a, but only libresolv.dylib is available. Just adding '-lresolv' to Makefile solves the problem.

Ruoming

Hi,

what version is this?

It's the latest version: 0.9a2. Let me download 0.8 and see if that compiles.

Ruoming

Somebody sponsor me a powerbook and I'll fix it in no time! *grin*

(Sorry I have no way to reproduce that ... good luck!)

Cheers,
Christian.

FYI, I'm having the same problem. Just created an account and see no
projects -- do those have to be assigned by the administrator?

Thanks,
Christian.

The mantis bro page is at:
http://crd.lbl.gov/mantis-bro/main_page.php

Cheers,
jason

Christian Kreibich wrote:

Hi!

I get a similar problem. I can see what looks like the main
Bro Mantis page, but when I click on "Report Bug", I can
only see "All Projects" as the "Choose Project" entry. If
I try to click on "Select Project", my browser stays in that
page.

-Chema

Hi,

I looked into this today ... thank Brian for prodding me -- you owe me a
beer because fixing this was painful and nobody has donated a powerbook
so far :slight_smile:

I am trying to compile Bro on a Mac OS X and encounter the following
two problems, both related to nb_dns.c:

The first is compile error. It is because the header file
arpa/nameser.h does not define HEADER, which is defined in
arpa/nameser_compat.h. nameser_compat.h will be included by nameser.h
only if BIND_8_COMPAT is defined, but I don't know if we should define
that. After including nameser_compat.h in nb_dns.c, it is able to
compile correctly.

[snip]

Next came the link error:

ld: Undefined symbols:
_res_9_dn_expand
_res_9_init
_res_9_mkquery
_res_9_ns_initparse
_res_9_ns_msg_getflag
_res_9_ns_parserr

This is because libresolv is not linked. Looking at the configure
script reveals that it looks for libresolv.a, but only libresolv.dylib
is available. Just adding '-lresolv' to Makefile solves the problem.

Okay ... well what I see here is that if BIND_8_COMPAT is defined,
nameser8_compat.h is included (note the "8"), and that causes
nonblocking lookups to be disabled because nameser8_compat does not
define ns_msg.

What I'm doing in the attached patch is

1. check whether you're running Darwin
2. if so, test whether just including arpa/nameser.h gives you HEADER
3. if 2 fails, include arpa/nameser_compat.h and use -lresolv instead of
/usr/lib/libresolv.a

Just using -lresolv in general bombs on at least Linux. *sigh*.

Build tested on Darwin, Linux, FreeBSD. Apply with -p1. The patch also
contains a few comments for configure.ac, and removes duplicated ones
for OpenSSL checks.

Fingers crossed,
Christian.

bro-resolver-darwin.diff (3.55 KB)

Christian,

Thanks for looking into it.

you owe me a beer because ....

Sure. :slight_smile:

Okay ... well what I see here is that if BIND_8_COMPAT is defined,
nameser8_compat.h is included (note the "8"), and that causes
nonblocking lookups to be disabled because nameser8_compat does not
define ns_msg.

What I'm doing in the attached patch is

1. check whether you're running Darwin
2. if so, test whether just including arpa/nameser.h gives you HEADER
3. if 2 fails, include arpa/nameser_compat.h and use -lresolv instead of
/usr/lib/libresolv.a

Just using -lresolv in general bombs on at least Linux. *sigh*.

Build tested on Darwin, Linux, FreeBSD. Apply with -p1. The patch also
contains a few comments for configure.ac, and removes duplicated ones
for OpenSSL checks.

I'm wondering if the problem is due to BIND 9 rather than Darwin. Just a random, unverified thought, as I haven't tried it on any other system that has BIND 9. But the FreeBSD on jaguar doesn't have BIND 9.

Ruoming

Hi!

I'm wondering if the problem is due to BIND 9 rather than Darwin. Just
a random, unverified thought, as I haven't tried it on any other system
that has BIND 9. But the FreeBSD on jaguar doesn't have BIND 9.

Yeah it might very well just be a bind issue -- in that case the check
should simply be moved from being darwin-specific to general. Frankly I
don't understand this stuff. I found a good deal of hits on google but
they all just suggest defining BIND_8_COMPAT which doesn't help us.

How can I realiably figure out what bind version a given resolver is
using?

Cheers,
Christian.