Bump - does anybody have any comments or suggestions? I'm also actively working with the Kea team to resolve the compilation problems in a less kludgy way; they're being tracked as kea#4785 and kea#4786. I've given them a patch for 4785 (the old SIZE_MAX problem), and am currently testing a patch for 4786 that should be more portable than the patch I've sent to this list. Hopefully, 3.4 will compile cleanly once it's released (assuming that log4cplus is upgraded.) On Mon, Aug 31, 2026, at 11:22, Stuart Lamble wrote: > 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. > Attachments: > * kea-3.2.0-openbsd.diff
No comments:
Post a Comment