You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#[link(name = "Mylib" )] works on the Windows, but Mac failed🚬
I try code in build.rs
let manifest_dir = std::env::var("CARGO_MANIFEST_DIR").unwrap();
println!("cargo:rustc-link-search=native={}", manifest_dir.display());
println!("cargo:rustc-link-lib=Mylib");
but also not work.
Stack trace
dyld[29363]: Library not loaded: @rpath/libMylib.dylib
Referenced from: <987AFB97-031F-3387-A7C3-047E9989602C> /Users/admir/Desktop/Code/rust-desktop-demo/src-tauri/target/debug/tauri-ts-demo
Reason: tried: '/System/Volumes/Preboot/Cryptexes/OS@rpath/libSampleBlueTooth.dylib' (no such file), '/usr/local/lib/libMylib.dylib' (no such file), '/usr/lib/libMylib.dylib' (no such file, not in dyld cache)
At first blush this looks like everything's working as intended if the library is at the project root (CARGO_MANIFEST_DIR) and you're launching the program from there.
I'm not at all familiar with Windows, but I believe it will pretty much always check the directory where the executable is and the current directory for libraries. This would explain things working if you're launching the app via cargo.
By default macOS will check the current directory as well. However in this case the native library was built in a way that tells the runtime linker to only look in the paths specified by the rpath. You can verify this with otool -D libMylib.dylib and see that the name listed begins with @rpath.
There are a few things you can try:
You can install the library into one of the rpath directories. otool -l target/… will list your application's rpath (look for LC_LOAD_DYLIB). rust-lang/cargo#5077 discusses how to change the rpath at build time.
Before you build your application you can change how the library identifies itself to the linker with install_name_tool.
At run-time you can include the directory where the library is in DYLD_LIBRARY_PATH.
You can change whatever's being used to create the native library to not prepend @rpath.
Activity
bjorn3 commentedon Aug 4, 2023
It looks like it successfully linked it, but you need to tell the dynamic linker where to find it using eg
DYLD_LIBRARY_PATHwhen running.inferiorhumanorgans commentedon Aug 5, 2023
At first blush this looks like everything's working as intended if the library is at the project root (
CARGO_MANIFEST_DIR) and you're launching the program from there.I'm not at all familiar with Windows, but I believe it will pretty much always check the directory where the executable is and the current directory for libraries. This would explain things working if you're launching the app via
cargo.https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order
By default macOS will check the current directory as well. However in this case the native library was built in a way that tells the runtime linker to only look in the paths specified by the rpath. You can verify this with
otool -D libMylib.dyliband see that the name listed begins with@rpath.There are a few things you can try:
You can install the library into one of the rpath directories.
otool -l target/…will list your application's rpath (look forLC_LOAD_DYLIB). rust-lang/cargo#5077 discusses how to change the rpath at build time.Before you build your application you can change how the library identifies itself to the linker with
install_name_tool.At run-time you can include the directory where the library is in
DYLD_LIBRARY_PATH.You can change whatever's being used to create the native library to not prepend
@rpath.RodBurman commentedon Dec 26, 2024
This looks to be a question about different OS's that has been satisfactorily answered, maybe we should close the issue?