AU issue

This is not really a JUCE issue, but nonetheless I’m hoping someone might be able to help me. I have a plugin that links to a 3rd party lib. In order to be able to test the plugin with auval through the debugger, I created a copy of auvaltool, as described on several threads here.

When I attach the plugin to my cloned auval in the Xcode debugger it passes all tests fine. But when I run it through the system auval it fails. My gut feeling is that it can’t find the 3rd party lib when the system auval tests the plugin. Note pluginval has no issues, it passes all but one test there. So perhaps AUs can no longer load third party libraries from system directories? I would rather not have to bundle and relink the lib for each phase of development.

Anyone any ideas on where to start with this? Btw, it’s a cannot open component -1 error that I’m getting. Oh, and no amount of cleaning the AU cache and restarting is helping!

I don’t understand why, but it is confirmed by several people here and on the forum, that auval in iterm2 only finds apple plugins. But in the regular terminal it works as it should.
Could that be the case? I battled a week with that.

(and strangely it affects pluginval as well IIRC)

Thanks @daniel. It seems that whatever auval is failing to load the plugin is the same one used in Logic, so the plugin is disabled. :frowning_face: I’ll take a look through that info. Thanks. Numerous attempts at relinking the 3rd party lib have failed, although I’m pretty sure if I just bundle it into the resources folder of my plugin and relink it will probably work fine :roll_eyes:

You might have to play with otool -L and install_name_tool to make it look in the bundle resources, but would be the cleanest way in the long run

In this case probably not as users can dynamically create plugins using my framework. Bundling the 3rd party lib into each of their exporting plugins is a complete waste of space. I just have to remind myself every so often to take a few moments away from the screen and repeat the mantra: it’s not me, it’s Apple, it’s not me, it’s Apple….

Does the exported plugin need the 3rd party lib to run?
Unfortunately the apple linker puts the absolute path to the lib in by default. You have to change it manually to @rpath

So how does this make any sense? When I run otool -L on my plugin library I get:

/Library/Frameworks/CsoundLib64.framework/Versions/6.0/CsoundLib64 (compatibility version 6.0.0, current version 0.0.0)
/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0)
/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 492.0.0)
/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 158.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 22.0.0)
/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)

It’s the Csound library I’m linking to, which I’ve never had issues with in the past. Now when i run auval on my plugin I get this:

aumf RORY Cabb  -  CabbageAudio: CabbageEffectNam
2020-01-29 11:11:35.235 auvaltool[1598:25303] Error loading /Users/walshr/Library/Audio/Plug-Ins/Components/CabbagePlugin.component/Contents/MacOS/CabbagePlugin:  dlopen(/Users/walshr/Library/Audio/Plug-Ins/Components/CabbagePlugin.component/Contents/MacOS/CabbagePlugin, 262): Library not loaded: @rpath/CsoundLib64.framework/Versions/6.0/CsoundLib64
  Referenced from: /Users/walshr/Library/Audio/Plug-Ins/Components/CabbagePlugin.component/Contents/MacOS/CabbagePlugin
  Reason: image not found
    Cannot open component: -50 

So clearly it is telling me what the problem is, i.e, it can’t find the library, but where in name of all that is holy is it getting that @rpath from? :angry: It’s not from the Csound library, an otool -L on that gives:

/Library/Frameworks/CsoundLib64.framework/Versions/6.0/CsoundLib64 (compatibility version 6.0.0, current version 0.0.0)
@loader_path/../../libs/libsndfile.1.dylib (compatibility version 2.0.0, current version 2.28.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)
/usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version 9.0.0)
/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0)

It’s very frustrating. Mostly due to the fact that this used to work fine. :man_facepalming: I know this is veering of into non JUCE territory, so I very much appreciate the help so far. Hopefully the clouds will break on this soon… :sun_behind_small_cloud:

After much pacing huffing and hawing, it looks like this was down to me failing to use sudo in one of my relinking commands. Why an OS would fail to report I don’t have permission to perform otool -change on a system installed library is beyond me. But it’s all good now. Now it’s failing for a valid reason. Thanks again @daniel for the input, as always.