Can't load plugin in Rack development mode on macOS

I would like to run Rack in “development mode” as documented on the Installing & Running page:

-d / --dev: Enables development mode. This sets the system and user folders to the current working directory, uses the terminal (stderr) for logging, and disables Rack’s Library menu to prevent overwriting plugins.

Ultimately I get a “Could not load plugin” error, described in detail below. I’m running the Rack 2.4.0 mac app and SDK. I get the same results on x64 and ARM. My example uses ARM since that’s my primary environment.

How to reproduce

  1. Define paths
export RACK_USER_DIR="/Users/gavin/Documents/Rack2Dev"
export RACK_APP="/Applications/VCV Rack 2 Pro arm64.app"
  1. Copy Rack system resources into the user directory since --dev mode expects the system and user resources to be in the same directory. Also create the plugins directory.
cp -r "$RACK_APP/Contents/Resources/"* $RACK_USER_DIR
mkdir $RACK_USER_DIR/plugins
  1. Build and copy plugin into the plugins folder
make dist
cp dist/LilacLoop-2.1.6-mac-arm64.vcvplugin $RACK_USER_DIR/plugins
  1. Launch Rack in --dev mode from the user directory
cd $RACK_USER_DIR && $RACK_APP/Contents/MacOS/Rack --dev
  1. Observe log output:
[1.215 info src/plugin.cpp:262 extractPackages] Extracting package /Users/gavin/Documents/Rack2Dev/plugins/LilacLoop-2.1.6-mac-arm64.vcvplugin
[1.218 info src/plugin.cpp:164 loadPlugin] Loading plugin from /Users/gavin/Documents/Rack2Dev/plugins/LilacLoop
[1.368 warn src/plugin.cpp:230 loadPlugin] Could not load plugin /Users/gavin/Documents/Rack2Dev/plugins/LilacLoop: Failed to load library /Users/gavin/Documents/Rack2Dev/plugins/LilacLoop/plugin.dylib: dlopen(/Users/gavin/Documents/Rack2Dev/plugins/LilacLoop/plugin.dylib, 0x0006): Library not loaded: /tmp/Rack2/libRack.dylib
Referenced from: <FE8D3C72-9BB3-39F8-BC3A-AA0919F1F136> /Users/gavin/Documents/Rack2Dev/plugins/LilacLoop/plugin.dylib
Reason: tried: '/tmp/Rack2/libRack.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/tmp/Rack2/libRack.dylib' (no such file), '/tmp/Rack2/libRack.dylib' (no such file), '/usr/local/lib/libRack.dylib' (no such file), '/usr/lib/libRack.dylib' (no such file, not in dyld cache)

I had to do two things to make it work:

ln -s $RACK_APP/Contents/Resources/libRack.dylib /tmp/Rack2/libRack.dylib

and

install_name_tool -change libRack.dylib \
  $RACK_APP/Contents/Resources/libRack.dylib \
  $RACK_USER_DIR/plugins/LilacLoop/plugin.dylib

I don’t know why

1 Like

Yeah, that /tmp/Rack2 link is strange. The Rack code seems to make and use it but in normal usage it’s never been present on my or many others macOS.

The ln -s … step allows me to run in development mode without problems. So I will leave it marked as the solution.

However, the existence of the /tmp/Rack2/libRack.dylib link seems to have broken my standard Rack installation (as opposed to my separate development mode installation). When that file is present, and I launch Rack the standard way, I don’t see any modules in my library (despite them being present in my user folder) and Rack offers to download them. I download them, restart Rack, and the same thing happens again: no modules in the browser, Rack offers to download them again. When I delete /tmp/Rack2/libRack.dylib the problem goes away.

So the steps I’ve taken to resolve my development mode problem have created new non-development mode problems, defeating the purpose of maintaining separate Rack installations for development and music making.

Maybe I’m outside the realm of what is supported by Rack. But I believe I’m using the --dev option as intended.

1 Like

Following up on a thread on Discord, I discovered the reason why your subscribed plugins don’t show up in the dev mode (-d) session anymore.

This appears to be intentional.

<rack source>/Rack/src/plugin.cpp:

	// Get user plugins directory
	if (settings::devMode) {
		pluginsPath = asset::user("plugins");
	}
	else {
		pluginsPath = asset::user("plugins-" + APP_OS + "-" + APP_CPU);
	}

On x64, it goes on to attempt to rename the old plugins path to the new one if it’s there, It also goes on to copy a Rack-bundled copy of Fundamental if it’s missing to wherever the plugins folder was resolved to. This explains why you only see Core and Fundamental in dev mode.

So, if you want your subscribed plugins to show up in a dev mode session, you’ll have to copy the contents of plugins-<OS>-<CPU> to plugins. (or hack this code and build your own copy of Rack without this behavior).

1 Like

I’m not expecting to see my subscribed plugins while running in development mode, given that a disabled library is a feature of development mode:

-d / --dev : Enables development mode … disables Rack’s Library menu to prevent overwriting plugins.

My goal is to have two separate Rack user folder installations on my system:

  1. My music-making user folder, which lives in the default location and contains subscribed plugins installed via the Rack library
  2. My development user folder in an arbitrary location where the plugins are managed by me (with the exception of core and fundamental plugins). This is the user folder Rack will point to in development mode. I don’t need my subscribed plugins to be installed here, and they won’t be because the library is disabled in development mode

My problem is:

The workaround required to use my dev user folder (2) in development mode somehow corrupts my music-making setup (1) and it appears to have something to do with the presence of the /tmp/Rack2/libRack.dylib file.

When I want to make music I need to take care that /tmp/Rack2/libRack.dylib doesn’t exist. And when I want to develop plugins I need to make sure that symbolic link points to the right place. I can’t explain why since I discovered this by trial and error.

So there is some friction when switching between those modes. It’s a minor annoyance, all things considered. But using development mode does seem harder than intended, at least on macOS.

1 Like

For development, just build rack yourself and build your own plugins under that. I.e. the old fashioned way.

That won’t help with the /tmp/Rack2/ problem which is a global thing.

No, you are correct. I was assuming the root issue is “I can’t develop plugins”. Doing it the way I suggested would fix that problem.