I maintain the MacPorts port for audacity and have been doing some work on it. This port uses a wxWidgets library version from MacPorts, as per official policy. Because audacity 3.x seems to be moving to making that less rather than better supported I decided to experiment with a +audacity build variant for the wxWidgets port which applies the audacity patches. I’m doing this on Mac (probably evident for those who don’t know me too well 
) and I’m building wxWidgets in CXX14 and compat30 mode.
I was expecting that those patches would consist of fixes and some transparent additional functionality. In other words, I was expecting that I’d be able at least to activate *) the +audacity wxWidgets variant if audicity had been built against the stock wxWidgets.
It turns out that the audacity build against the one wxWidget variant won’t run against the other because at of least one missing symbol: _ZThn1344_N10wxTextCtrl3CutEv or _ZThn1352_N10wxTextCtrl3CutEv (expected in libwx_osx_cocoau_core).
Both demangle to “non-virtual thunk to wxTextCtrl::Cut()”.
This strikes me as very odd; why would even an internal C++ support function get mangled to a different name because of patches that do not even modify the class in question (as far as I can tell)? Am I overlooking a change to something fundamental that introduces an ABI incompatibility?
*) MacPorts supports having multiple versions or variants of a port installed, and activate one of them.