On 11/12/2013 11:47 AM, Darrin Cardani wrote: Paul, Did you ever get this resolved? If not, I’ve got some questions below. I had this kind of structure: PLUGIN SET 1 <bunch of C++ code> FxPlugInterface (objective C class) filters are subclasses of FxPlugInterface PLUGIN SET 2 <bunch of C++ code - possibly slightly different from set 1> FxPlugInterface (objective C class - slightly different from 1) filters subclasses of FxPlugInterface To fix it I had to actually make a "FxPlugInterface2" for PLUGIN SET 2. _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com It wasn't actually a C++ collision, but the wrong C++ code ended up being called (even though it was all statically linked and stripped) because the wrong FxPlug class was getting called. I had it set up to only "export" (via the symbols.txt file) only the list of per-filter Objective C classes, which are all unique. But despite all that, when filters from either set were instantiated, it was randomly choosing the FxPlugInterface class from either one, which resulted in crash dumps down in the "wrong" C++ code. I had forgotten that even though symbols may be "hidden" or stripped, once the code is loaded all bets are off if they are Objective C classes (what a lovely feature). The upshot is I'll have to rev my "FxPlugInterface" class with a version number every time I change it, either in an updated or new set of filters.