I have a few third party libraries - protobuf being one of them. For years I have linked against the .dylib, and then I install that with my plugin. I use dyblibbundler to remap the path to the .dylib to its final installed location, which is Contents/Frameworks. This has worked for years.
Recently, I had a Pro Tools crash report. After sending it to Avid (because they insist on encryption), they indicated that the crash was in a Waves plugin that was calling into my protobuf dylib. I didn’t even know it was possible for another plugin to use my third party libraries (??). I use an older version of protobuf, so I’m theorizing that the Waves plugin is expecting a much later version of protobuf with some new API, and instead they get my old lib and crash on a missing API or something. As a quick fix, I have updated to the latest protobuf - this seems to help.
But, I started wondering if I should be statically linking the third party .a’s instead of using .dylib’s (?). I did a quick experiment by adding -static to my linker flags (xcode). Now all of the std c++ runtime functions don’t link, and I don’t see an option for a static runtime. Am I barking up the wrong tree?