From: Marc Espie Subject: summing up: the kicad issue To: tech@openbsd.org Date: Fri, 7 Mar 2025 21:23:21 +0100 - kicad doesn't run correctly on either FreeBSD or OpenBSD after the last update (made necessary because of the python update) - sthen@ has suggested we "unbreak" kicad and make it non executable, because pkg_add -u would be annoyed. - the basic problem is a difference between libstdc++ and libcxx. libcxx has a more pedantic approach to solving dynamic_cast. - the gory details lie in /usr/src/gnu/llvm/libcxxabi/src/private_typeinfo.cxx look up the _LIBCXXABI_FORGIVING_DYNAMIC_CAST define IMO there is a problem with that define, which encompasses two completely distinct behaviors: -> emitting a diagnostic for problematic typeinfo information -> using a simple-minded (strcmp based!) work-around strategy that's (mostly) compatible with libstdc++. There are several actions that could be persued related to that issue. - thanks to the heroic sleuthing of rsadowski, we know that the problem lies there. Unfortunately, enabling forgiving dynamic casts yields the ambiguous error near line 701: dynamic_cast error 2: One or more of the following type_info's has hidden visibility or is defined in more than one translation unit. They should all have public visibility looking further, those typeinfos are hidden, AND they may be multiply defined (thanks to the pcb_kicad code) Making those diagnostics non optional seems like the right thing to do in OpenBSD (I understand that they're optional because windows doesn't have syslog, but we have numerous examples of non-kosher stuff that leaves traces in syslog already), independently of the work-around. - explaining properly to the kicad people that the problem is related to libcxx and not libstdc++ - evaluating the idea of enabling that compatibility mode There is an olden post initiated by Akim Demaille in 2015 on stackoverflow: https://stackoverflow.com/questions/19496643/using-clang-fvisibility-hidden-and-typeinfo-and-type-erasure This is the best write-up I could find on this exact problem. The end answer "hack", unfortunately, doesn't quite work (emulating dynamic_cast is complicated). Evaluating the pros-and-cons: I think that we should enable forgiving dynamic casts for now. I understand the pedantic attitude of the llvm people, and yes, frankly this problem ought to be fixed eventually, but for now, I think there is a very low probability that local typeinfos will match exactly (especially with most C++ developers using namespaces and removing collisions) - one further venue to investigate, looking at the comments in private_typeinfo.cpp, is that both functions doing the typeinfo traversal, up and down, are obfuscated optimized versions of a much simpler algorithm. I wonder what would happen if we just used the unoptimised version (and analyzed it further to AT LEAST store a better diagnostic in info, just so we know for sure whether it's a visibility problem or a multiple definition problem). Lastly one last problem got me stumped: is there a reasonably simple way to tell clang to change the visibility of a class's typeinfo (or make it weak to work-around the multiple definition issue). This could use some fresh eyes, and it's definitely an annoying issue that waaay too many people have lost a lot of time on so far !!!