Recompiling analog_sdk_wrapper.dylib with relative path for packaging, MacOS

[DrMechanica]

So I'm trying to embed the analog_wrapper dylib into an app bundle I'm working on with Xcode, but the application can't find the dylib because it's install path is wrong. So the app compiles, but immediately errors with:
dyld: Library not loaded: /Users/travis/build/WootingKb/wooting-analog-sdk/target/x86_64-apple-darwin/release/deps/libwooting_analog_wrapper.dylib
Referenced from: /Volumes/AUX/MovedUsers/mechanica/Documents/JUCE Apps/Wooting Test 2/Builds/MacOSX/build/Debug/Wooting Test 2.app/Contents/MacOS/Wooting Test 2
Reason: image not found

From what I can tell, I need to recompile the dylib with a relative install_name linker flag, but I'm having trouble finding an easy way to do this, as I'd really like to avoid adding anything to DYLD_LIBRARY_PATH. I was hoping it was something I could set in the cargo.toml, or the makefile perhaps, but Rust is completely new to me.
Interesting discussion here on the subject, though some of it is a bit over my head.

Is there an easy way to fix this?

[simon-wh]

Hmmm, I don't have a Mac so I'm going to struggle with effectively helping you. I've found this post which seems to be a bit more relevant. Based on that, I'm going to set it up to compile with rpath support as mentioned in the answer.

[DrMechanica]

Thanks so much for the unbelievably expedient response! I really appreciate the help.
Snap, I actually came across that too and I guess I didn't read the answer thoroughly enough.

[simon-wh]

No problem! You caught me at the right time aha. I'm currently trying to push a new release that includes the mentioned change which will hopefully resolve your issue. However, the windows build is playing up so it's a bit delayed, but I have the Mac build if you wanna give it a try to see if it works.
wooting-analog-sdk-v0.4.0-x86_64-apple-darwin.tar.gz

[DrMechanica]

Awesome, I'll give it a try!
After reading your initial response I actually went and added the rpath enabling profile to the top-level cargo.toml of the version I had already downloaded and got it to work.

...

Okay, so I tried the download you linked and the precompiled dylib unfortunately still seemed to have the absolute path issue? I've attached my copy of the SDK source with the fixed top-level cargo.toml and a proper rpath-ed build of the dylib for you, just in case it's useful. Only change is the cargo.toml (and I removed the analog-test-plugin folder, because it was huge.)
wooting-analog-sdk-0.2.0 (fixed).zip

[simon-wh]

Ah, I see, thanks for getting one working on your end! I had just put the rpath on the wrapper Cargo.toml. But I guess it works more effectively when put in the workspace toml, thanks! I'll throw your change in for release v0.4.0

[simon-wh]

Could you try the v0.4.0 build to verify that it's fixed in the release builds?

[DrMechanica]

Perfecto! I tested and it all works. Glad we got it worked out!

Yeah, my first instinct was the same, to put the rpath profile on just the wrapper. But when I compiled that way I noticed a warning in the console:
warning: profiles for the non root package will be ignored, specify profiles at the workspace root:
package: /Volumes/AUX/MovedUsers/mechanica/Downloads/wooting-analog-sdk-0.2.0/wooting-analog-wrapper/Cargo.toml
workspace: /Volumes/AUX/MovedUsers/mechanica/Downloads/wooting-analog-sdk-0.2.0/Cargo.toml
So I guess profiles always have to be set at top level, for whatever reason.

[simon-wh]

Awesome! Glad it's sorted for you!

Ah, I see, I must've missed that in my log. Thankfully you picked up on it ahaha.

If you have any feedback on the SDK or further issues don't hesitate to let me know!