- 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 !!!