Re: [tcpdump-workers] NetBSD breakage
--- Begin Message --- On Thu, 12 Aug 2021 01:18:45 +0100 Denis Ovsienko via tcpdump-workers wrote: > On Wed, 11 Aug 2021 15:38:34 -0700 > Guy Harris wrote: > > > I've checked in a change to remove the include of grammar.h from > > gencode.c; it builds without problems on macOS, and I suspect it > > will build without problems everywhere > > Thank you, NetBSD has recovered now. I am going to remove > HAVE_SYS_TYPES_H from pcap/bpf.h because it does not belong there. As usual, better late than never, so the above has been done in commit 19e2a37 in the master branch. I am going to cherry-pick that into the libpcap-1.10 branch before the 1.10.2 release. -- Denis Ovsienko --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] NetBSD breakage
--- Begin Message --- On Wed, 11 Aug 2021 15:38:34 -0700 Guy Harris wrote: > I've checked in a change to remove the include of grammar.h from > gencode.c; it builds without problems on macOS, and I suspect it will > build without problems everywhere Thank you, NetBSD has recovered now. I am going to remove HAVE_SYS_TYPES_H from pcap/bpf.h because it does not belong there. -- Denis Ovsienko --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] NetBSD breakage
--- Begin Message --- On Aug 11, 2021, at 3:09 PM, Denis Ovsienko via tcpdump-workers wrote: > The other matter is that the gencode.h/grammar.h pair works best when > it is included early. Perhaps the gencode.h/grammar.h pair works best when it doesn't include grammar.h. :-) I've checked in a change to remove the include of grammar.h from gencode.c; it builds without problems on macOS, and I suspect it will build without problems everywhere, as what grammar.h defines are: 1) the names for tokens (which may be done with an enum in a fashion that causes large amounts of pain if another header you include helpfully - but uselessly, for our purposes - names for the machine's registers, and you are unlucky enough to be compiling for a machine that has a register named "esp", causing a collision with the "esp" token in pcap filter language for ESP; fortunately, such machines are rare :-) :-) :-) :-) :-) :-(); 2) a union of value types for all symbols in the grammar. As far as I can tell, neither token names or values nor a value type union are passed to any of the gencode.c routines called from grammar.y. We *do* pass values for symbols, but we select the particular union member, rather than just blindly passing the union as a whole. So far, all the libpcap builds om www.tcpdump.org are green except for the Windows build, which is listed as pending; it's about 2/3 of the way through the build matrix.--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] NetBSD breakage
--- Begin Message --- 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 . 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
