debugging max external in OSX

    Jan 14 2014 | 9:19 pm
    I'm currently building an external that requires an external dynamic library.
    It works fine in Windows.
    In Mac OSX, I first had trouble linking the dylib - no matter how I set the copy build phase to get the dylib into the Frameworks, Executable or Resources folder of the external app bundle, it fails to load with an error stating the dylib cannot be found. I understand this is a standard dylib issue. A quick fix is by putting the dylib into /usr/lib, and it no longer complains. However, then it simply fails to load without any error output. I have tried debugging by attaching XCode to the Max Runtime, and loading a patch containing the external, but it looks like its failing before the external code is loading (doesn't trigger breakpoints in the constructor). I think the debugging environment is set up properly as I can hit the breakpoints correctly if I try to load another sample external that works.
    Anything to point me in the right direction would be greatly appreciated. Thanks in advance!
    *edit* I've set up the library now using rpath and bundled into the .mxo, so it loads more elegantly, but still, the external that uses the object just turns up red, without any error output.

    • Jan 15 2014 | 6:41 am
      I have only done this once, and don't understand why or how it all works… but here is a screenshot of how it (seems to) works for me… HTH!!
    • Jan 15 2014 | 7:35 am
      Nicolas, can't believe I didn't see that example! I will follow it closely and see what happens. Thanks! Right now the problem is during instantiation time - the gist of it I had painfully figured out from other documentation for the library install/linking/runtime paths: when not set up properly, I get a error in the Max window during instantiation. It's when I have it set properly (as far as I know) that the silent error occurs, and I had no idea where to look.
      I have a feeling it's close now - the concrete working example is a great help. Thanks again!
    • Jan 16 2014 | 4:55 am
      update: oh my, FINALLY figured it out.
      turns out, as I was messing around with the example, I changed the name of the package name (name.mxo), but did NOT change the name passed to the class_new() function!!! d'oh! would have been nice to see an error message, but... still totally my own fault for getting into this predicament!
      thanks again everyone!