After observing that Kea in OpenBSD's ports is old (2.4.2), I took it upon myself to try to compile 3.2.0. I succeeded (see caveats at the end of the email). What needed to be done:
* Install the packages unzip, python-3, cmake-4.2.3v1, git-2.53.0, boost-1.89.0p1v0. * Compile and install log4cplus 2.2.0.1 (the available package is version 1.2.2; trying the packaged version resulted in the error "no template named 'auto_ptr' in namespace 'std'" - it appears that that's a deprecated/removed C++ feature, and Kea has moved to a more recent C++ version that no longer understands it.) * meson.sh setup build - succeeded. Then I ran meson.sh compile -C build. This failed in two ways. First: struct bpf_timeval. I cloned Pkt::addPktEvent in src/lib/dhcp/pkt.cc (the version that accepts struct timeval) and modified the clone to accept struct bpf_timeval (the cloned function is otherwise identical), after validating that struct bpf_timeval and struct timeval appear to be essentially identical (in their member names, if not the member sizing). I added a #include <net/bpf.h> in pkt.h to ensure it was available. Second: I bumped into the old SIZE_MAX problem (https://gitlab.isc.org/isc-projects/kea/-/issues/2970). I applied the bodge patches that are in the ports tree. Once I got past both of those issues, it compiled without any further problems - just a warning about rand() and random() potentially being deterministic. Having successfully compiled the code, I now want to understand what the next steps would be to get the updated Kea into the ports tree: validation, peer review, etc., etc. I haven't done C++ programming since I was in university, which was decades ago, so my confidence in the correctness of the patches is not as high as I would like it to be, though I am reasonably confident. I also appreciate that bumping log4cplus from 1.2.2 to 2.2.0 is a significant change and could have implications for other packages. Of particular concern to me is that there are patches in the ports tree for kea-2.4.2 that seem to be unnecessary to compile 3.2.0, but I don't understand their purpose in the context of 2.4.2. My focus to this point has been on the minimum changes required to get the code to compile - I fully appreciate that "compiling" is not the same thing as "producing a correctly functioning binary", as well as acknowledging that I do not understand the code base well enough to even begin to test it adequately. I also note that this build may, or may not, work correctly with MySQL or PostgreSQL - again, the focus to this point has solely been on compilation, and not validating functionality. I've attached the diff to this email. If it matters, this compilation was done on an arm64 host (virtualised on an Apple M1 Max system). Thanks, Stuart.
kea-3.2.0-openbsd.diff
Description: Binary data
