Libloading issue on os x

using libloading on os x, I have stumbled upon an issue with what I assume to be dynamic library dependencies not getting found.

I have been playing with an example, which, when compiled and run, crashes with this:

It would seem that the issue is an inability to find this @rpath/libstd-abe443acf5b6ec18.dylib

For reference, using otool -L on the dynamic lib yields this:

	/Users/jgerber/src/rust/pes-dylib/target/debug/deps/libmy_plugin.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libstd-abe443acf5b6ec18.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
	/usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)

Interestingly, the example that i am playing with works fine if you run the executable via cargo run. I assume that cargo run adds some additional contextual info that the loader uses...

When using cargo run, DYLD_LIBRARY_PATH gets extended in two places. First rustup adds $(rustc --print sysroot)/lib, which is where libstd-*.dylib lives. Second cargo adds target/debug or target/release for any dependencies built as dynamic libraries. In this case only the first one matters. You can either use rustup run stable your_command or manually set DYLD_LIBRARY_PATH=$(rustc --print sysroot)/lib.

Thanks Bjorn.

I was hoping to find a way to do this without setting the LD_LIBRARY_PATH. I am writing something which may be run as a setuid affair, and in that case the LD_LIBRARY_PATH is ignored...

You likely will either need to copy libstd-*.dylib to somewhere like /usr/local/lib. Are you going to store the plugin there too? It should not be somewhere user-writable to prevent privilege escalation.

we have an inhouse package system which is served over nfs. The packages are non-writable...

I know that I can use install_name_tool to add a path to the executable. that works. Just was hoping there was a cargo solution...