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.
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.