Building shared libraries on Mac requires '-undefined dynamic_lookup'

[jeff-davis]

Problem

A shared library used as a plugin will often reference symbols in the host program. These symbols will remain unresolved at build time, but will be resolved at the time the shared library is loaded into the host program.

Cargo on Mac fails to build any shared library that can't resolve the symbols at build time.

I expect cargo to build a crate containing unresolved symbols successfully; which works fine on ubuntu.

Steps

A crate with the following Cargo.toml:

[package]
name = "fail"
version = "0.1.0"
authors = ["jefdavi"]
edition = "2018"

[lib]
crate-type = ["cdylib"]

and src/lib.rs:

extern "C" {
  static unresolved: i32;
}

#[no_mangle]
extern fn myfunc() {
  unsafe {
    println!("{}", unresolved);
  }
}

Possible Solution(s)

A workaround is to specify:

[build] rustflags = ["-Clink-args=-undefined dynamic_lookup"]
in .cargo/config, but that's not acceptable for a crate author (https://github.com/jeff-davis/postgres-extension.rs), who doesn't have control over the crate users' config files.

Notes

Output of cargo version:

cargo 1.36.0 (c4fcfb725 2019-05-15)

18.6.0 Darwin Kernel Version 18.6.0

[alexcrichton]

Thanks for the report! This is more of an issue for rust-lang/rust than Cargo, so I'm going to transfer it there.

[danielkeller]

My 2 cents on this:

A better solution would be to add a variant of the #[link(name = ...)] extern {} attribute with something like #[link(dynamic)] extern {}, that gives the linker the flag -U <symbol> for each symbol in the extern block. This will make it possible to locate symbols dynamically, if the programmer chooses, but keep the ability to detect undefined symbols at link time in general.