tcpdump mailing list archives
NetBSD breakage
From: Denis Ovsienko via tcpdump-workers <tcpdump-workers () lists tcpdump org>
Date: Wed, 11 Aug 2021 23:09:38 +0100
--- Begin Message --- From: Denis Ovsienko <denis () ovsienko info>
Date: Wed, 11 Aug 2021 23:09:38 +0100
Hello list. I have spent some time looking into tcpdump NetBSD builds, which all have failed as a consequence of my libpcap commit 0c21cb27, which had broken the workaround earlier introduced in libpcap commit bb02779. As Guy has noted in a comment just now, the matter isn't just about bpf_u_int32, but also BPF_MEMWORDS. These two simple props (one of which also depends on u_int) currently have a side effect of including pcap/dlt.h, which involves enough system headers to touch <net/dlt.h>. Then the problem is that the NetBSD header and the libpcap header compete for the same DLT_MATCHING_MAX (ifdef/undef/define), so there is only one way to include them to have the right definition at libpcap build time. The other matter is that the gencode.h/grammar.h pair works best when it is included early. I have been following header dependencies for some time, and it is clear that it would be nice to have one of the public headers make trivial declarations that do not introduce side effects. So, for example, pcap-inttypes.h could have the bpf_int32/bpf_u_int32 block instead of pcap/bpf.h (plenty of files use these types). In this case it would also make sense to merge pcap-types.h into pcap-inttypes.h. I do not see what would be a good place for BPF_MEMWORDS, but clearly it is a named constant and having it declared should not depend on any other headers at all. -- Denis Ovsienko
--- End Message ---
_______________________________________________ tcpdump-workers mailing list tcpdump-workers () lists tcpdump org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Current thread:
- NetBSD breakage Denis Ovsienko via tcpdump-workers (Aug 11)
- Re: NetBSD breakage Guy Harris via tcpdump-workers (Aug 11)
- Message not available
- Re: NetBSD breakage Denis Ovsienko via tcpdump-workers (Aug 11)