Open
Description
This originated from #565
Originally posted by jamesblacklock October 12, 2021
I'm getting the following error when I do a cargo run
(seems to be just the run
; build
works fine):
dyld: Library not loaded: @rpath/QtCore.framework/Versions/A/QtCore
Referenced from: /Users/<snip>/target/debug/budget
Reason: image not found
Has anyone seen this error or have any familiarity with getting the sixtyfps qt backend working on macos?
When creating a rust binary with cargo and sixtyfps found Qt available for use, we may want to code the rpath
to the Qt library/frameworks on Linux and macOS.
The path is initially determined in qttypes's build.rs
and printed via
println!("cargo:rustc-cdylib-link-arg=-Wl,-rpath,{}", &qt_library_path);
Unfortunately this has two problems:
- It only "works" when creating a cdylib, so for example the C++ API of SixtyFPS, but not when creating a Rust binary.
- The option will cease working in a transitive way as per Tracking issue for
rustc-cdylib-link-arg
transitive warning rust-lang/cargo#9562
However that cargo issue also suggests a solution that we could implement, which is two fold:
- We need
rustc-link-arg
to show up in a stable release of rust/cargo. - Inside SixtyFPS we need a reliable way to get hold of the correct rpath and then offer API that applications can call from their
build.rs
that will emit the correctrustc-link-arg=-Wl,rpath,...
text to stdout. This could be done automatically bysixtyfps_build::compile()
but perhaps there's also a way to offering either a function forbuild.rs
for apps using the macro or the macro could somehow emit#[link_arg(...)]
.