Depending on files from another crate

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?

1 Like

Crates can cooperate in a complicated two-step process.

Assuming A depends on B.

B gets built first:

  1. B must have links attribute set to globally unique string.
  2. B copies files to path from OUT_DIR env var.
  3. B prints cargo::my_out_dir_is= with value of OUT_DIR.

A gets built second:

  1. A reads env var DEP_<name from B's links attr>_MY_OUT_DIR_IS
  2. That's where the files are.

…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:

Probably so. I explain some more context here (rejected PR):

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 (, 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.