Skip to content

Building shared libraries on Mac requires '-undefined dynamic_lookup' #62874

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

Open
jeff-davis opened this issue Jul 19, 2019 · 3 comments
Open
Labels
A-linkage Area: linking into static, shared libraries and binaries O-macos Operating system: macOS T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@jeff-davis
Copy link

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
Copy link
Member

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

@alexcrichton alexcrichton transferred this issue from rust-lang/cargo Jul 22, 2019
@Centril Centril added O-macos Operating system: macOS A-linkage Area: linking into static, shared libraries and binaries T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 23, 2019
jeff-davis added a commit to jeff-davis/rust that referenced this issue Nov 20, 2019
Necessary for shared libraries where not all symbols are resolved
until the library is loaded at runtime.

Fixes rust-lang#62874
@danielkeller
Copy link

danielkeller commented Nov 9, 2021

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.

@MatrixDev
Copy link

@danielkeller it is fine for the linux (already works like this) and macos/ios (will work). But what about windows and android? AFAIK those platform don't support dynamic linking (I might be wrong).

Maybe it is better to just make this a default behaviour for macos?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-linkage Area: linking into static, shared libraries and binaries O-macos Operating system: macOS T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants