Errors compiling bro-pub-0.8a32 on Linux 2.4.20-8

[Christopher Jay Manders]

>>Dict.cc: In member function `void* Dictionary::NextEntry(HashKey*&,
>>    IterCookie*&, int) const':
>>Dict.cc:260: choosing `HashKey::HashKey(const void*, int, unsigned int)' 
>>over `
>>    HashKey::HashKey(void*, int, int)'
>>Dict.cc:260:   because worst conversion for the former is better than worst
>>    conversion for the latter
>>Dict.cc:288: choosing `HashKey::HashKey(const void*, int, unsigned int)' 
>>over `
>>    HashKey::HashKey(void*, int, int)'
>>Dict.cc:288:   because worst conversion for the former is better than worst
>>    conversion for the latter
>>make: *** [Dict.o] Error 1
>>
>>
>>This error looks more programatic to fix, so this will take more time. 
>>Anyone with thoughts on this one?
> 
> 
> Good catch by the compiler - this points out a warning in which two
> calling sequences with quite different semantics could be confused due
> to the implicit conversion rules.
> 
> I've changed the calling sequence of one of the calls to avoid the
> possible ambiguity.



It looks like the main thing that you changed was the class definition 
in Hash.h (at least for this).

That seems better than hardcoding the suggestion of casting each entry-> 
reference to make it fit one of the overloaded HashKey::HashKey 
functions. One has to assume the right one to cast the args towards it.

FYI: the last problem with the build on Linux is the same as for OpenBSD 
with the HAVE_NB_DNS.

You are right that undefining that and getting rid of the nb_dns.o in 
the OBJ section of the Makefile seem to have the build working. This 
works with Linux as well.

There must be a better way of using res_mkquery to assure that this 
calls in the nb_dns.c will work s expected. I do note that nb_dns.h does 
not even exist on my Linux box, but res_mkquery calls work if I use the 
<netinet/in.h> <arpa/nameser.h> and <resolv.h> includes. The same is 
true on OpenBSD, BTW.


Cheers!

Chris