-
Notifications
You must be signed in to change notification settings - Fork 38
#[link(name = "...")]
is poorly supported
#62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
A reasonable solution might be to have a fixup (or default behavior...) to propagate |
It looks like |
We do have support in the buck2 prelude to enable nightly features on non-nightly toolchains. Setting https://github.com/facebook/buck2-prelude/blob/main/rust/rust_toolchain.bzl#L128 |
Thanks! That should work well in practice. Ideally we could set this flag without also globally enabling nightly features, which might not otherwise be desired, but that's a fairly small footgun. |
For posterity: Passing |
Some FFI crates define bindings with the form
#[link(name = "foo")] extern "C" { ... }
, and rely on the buildscript to emit acargo:rustc-link-search
directive to find thefoo
library, whose unqualified name is forwarded directly to the linker by rustc. Reindeer silently drops therustc-link-search
directive, leading to linker failures when those FFI definitions are statically used. Major examples includepyo3
andwindows-sys
.A workaround is to place these libraries in a
filegroup
, then arrange for that filegroup to be added to the linker's search path vialinker_flags
in downstream targets or the toolchain. I haven't managed to getlinker_flags
in a fixup to do anything.The text was updated successfully, but these errors were encountered: