On Sun, 16 Feb 2025 23:05:09 -0500, Arjun Ray <ara...@gmail.com> wrote:
| To fix this, either the file m4/find_cppunit.m4 will have to be | modified - which could be non-trivial as pkg-config is not a drop-in | replacement for cppunit-config - or we can deploy a custom version of | cppunit-config (that basically wraps a call into pkg-config). In the event, I ended up writing a cheesy shell script to return hard coded values culled from the cppunit.pc file installed by the package. That seemed to satisfy the build m4 macros, and everything compiled successfully. All the tests passed as well (2070 regular tests, 133 integration tests.) I'm now down to one warning. 1. The obsolete ASN1_STRING_data() function has been replaced by ASN1_STRING_get0_data, which is obviously a drop-in replacement (it simply "const"s the argument and return type.) This will break only old systems (which aren't likely to have C++17 compilers anyway.) 2. The business with (volatile void **) has a workaround. I replaced the call to : Atomics::compareAndSet((volatile void **)(&node->next), (void*)expect, (void*)update); with a call to a templated function in the same file : Atomics::compareAndSwap<Node>(&node->next, expect, update); which expands to the same underlying call within Atomics.h. That seemed to mollify the compiler. 3. The last remaining warning has to do with a commonly recurring issue in the codebase: the class has a user-defined copy constructor but no corresponding cpy-assignment operator (hence created by the compiler, but with a warning). The offending class in this instance is decaf::util::HashSet<int>. This is the Rule of Three (now Rule of Five for move semantics), where if any of (1) destructor, (2) copy constructor, or (3) copy-assignment operator are not defaulted (i.e left to the compiler to create implicitly), then none of them should be (because construction / destruction may need special treatment, such as pointer deletion.) C++11 introduced a language feature to specify "default" or "delete" for the declaration of these implicit functions. Fixing HashSet<> is complicated by its internals, which unfortunately is clearly a remarkably wooden translation of Java code. It may turn out to be straightforward to fix, but I'd need to be careful with such heavily non-idiomatic code. Summing up, all these changes, while extensive, are internal only. Nothing has changed in terms of user-facing APIs. If 3.9.5 is the current latest version, I suggest making this 3.9.6, with a prominent annotation somewhere that this is simply an upgrade for C++17 compliance. Those who don't need that can continue to use 3.9.5 for the same functionality. Arjun --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org For additional commands, e-mail: dev-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
