Is it possible to depend on special files from another crate, which can then be used during the build process?
For instance, let's say that crate A builds a file containing information for the linker, and crate B depends on crate A. How should crate B get that file from crate A, and then pass it to the linker?
That sounds like a bad idea. What is the problem that you're trying to solve by doing that?
Crates can cooperate in a complicated two-step process.
Assuming A depends on B.
B gets built first:
links attribute set to globally unique string.OUT_DIR env var.cargo::my_out_dir_is= with value of OUT_DIR.A gets built second:
DEP_<name from B's links attr>_MY_OUT_DIR_IS
…but Cargo crates can't specify linker options beyond -l, and you should never set -l for another crate. Every crate links its own thing: Using C libraries in Rust: make a sys crate
Probably so. I explain some more context here (rejected PR):
https://github.com/rust-lang/rust/pull/66204
Basically, I have a crate designed to help writing Postgres extensions in rust. A postgres extension is intended to be loaded into postgres, and call various C APIs. So at the time the postgres extension is linked, many symbols are intentionally unresolved. This works on linux but fails on Mac and windows with default linker flags.
I was looking into how to solve this on windows. It appears that a Module Definition File might help with this, but I wouldn't expect each extension to try to maintain this file. So, one idea was to include this in my crate (postgres-extension.rs), and have the postgres extensions pass this file to the linker. But I'm not sure if that's really possible with the cargo build system.
That sounds like a good workaround for me to try, thanks!
I'm hoping that there's some way that rust can support cdylibs where it's expected that there are some unresolved symbols (i.e. a plugin-style shared library).
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.