Re: [Patch] building nmap-4.03

[Fyodor <fyodor () insecure org>]

On Tue, May 30, 2006 at 08:52:06AM -0500, Peter O'Gorman wrote:
> We just build nmap-4.03, and had some issues, mostly with AIX and
> libdnet. 

Thanks for the feedback!

> There are some serious problems with libdnet on AIX. Although a
> separate download of libdnet itself actually builds, it is unusable. The
> headers conflict with system headers. For example, aix has '#define
> ip_v    ip_ff.ip_fv' in netinet/ip.h, which causes great compiler
> confusion when it is included after dnet/ip.h which has "uint8_t
> ip_v:4". We went through these and preixed them with dnet_.

I must admit that I'm kinda loathe to make such an ugly change just
for AIX.  Have you found any other ways to resolve the problem?  Maybe
reordering header includes, or not including netinet/ip.h on AIX?

> In a few places, libdnet has '# define __attribute__(x)' which is okay,
> but the compiler barfs if __attribute__ is already defined, so we
> #ifndef __attribute__ around them.

Applied.

> Aix #defines ICMP_INFOTYPE, icmp_gwaddr, icmp_pptr, since nothing
> appears to use these, we simply removed them from libdnet.

Can you think of any ways to accomplish this without removing these
from libdnet?  Or at least I'd rather wait until we can find a
solution to the ip_v and ip_hl issues before making this change.

> While aix does have a radix.h, and it appears mostly compatible with the
> tru64 version, the #ifdef here is really checking for tru64, aix does
> not have some of the structs and members being used:
> "route-bsd.c", line 474.37: 1506-022 (S) "rnh_next" is not a member of
> "struct radix_node_head".
[cut]
> is undefined.
> I cheated here, and just added && ! defined (_AIX)

Applied.

> To get away from aix for a bit, hpux-10.20 does not have SIOCGIFMTU or
> SIOCSIFMTU. It had other issues also, and I again cheated and did:
>   ac_cv_header_hpsecurity_h=no
>   ac_cv_header_sys_mib_h=no
> before configure. While these headers exist, they differ significantly
> from hpux11 and nmap does not build with them.

I would be happy to apply this if you can find a cleaner way.

> For slightly more normal issues, nmapfe/nmapfe_sig.c declares a variable
> in the middle of a block, this is not accepted by all compilers. We also
> had to cast the return value of a gobject_get_data to a function
> pointer.

Applied.

These changes should be in the next version of Nmap, which I hope to
release by Monday.

Cheers,
-F


_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev