Skip to content
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

a static library is not linked properly to a required system library #110143

Open
conanoc opened this issue Apr 10, 2023 · 3 comments
Open

a static library is not linked properly to a required system library #110143

conanoc opened this issue Apr 10, 2023 · 3 comments
Labels
A-linkage Area: linking into static, shared libraries and binaries C-bug Category: This is a bug.

Comments

@conanoc
Copy link

conanoc commented Apr 10, 2023

Problem

I created a crate as a static library named libaries_askar.a. When I create an Xcode project that uses this library, build fails with the following error:

Undefined symbols for architecture x86_64:
  "_SCDynamicStoreCopyComputerName", referenced from:
      whoami::platform::devicename_os::hfd1ed897939614da in libaries_askar.a(whoami-3e3bd00337b8ac7e.whoami.50980d84-cgu.12.rcgu.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I could resolve this link error by importing SystemConfiguration framework in a swift file of my app.

#if os(macOS)
import SystemConfiguration
#endif

Steps

  1. Create a crate that depends on the "whoami" crate.
  2. Build the crate as a static library.
  3. Create an xcframework of the library.
  4. Create a Swift package and add the xcframework as a binary target dependency.
  5. Build the package.

Possible Solution(s)

No response

Notes

  • I only tested this on macOS, not on iOS.
  • I'm not sure if this is a bug or not.

Version

cargo 1.67.1 (8ecd4f20a 2023-01-10)
release: 1.67.1
commit-hash: 8ecd4f20a9efb626975ac18a016d480dc7183d9b
commit-date: 2023-01-10
host: x86_64-apple-darwin
libgit2: 1.5.0 (sys:0.16.0 vendored)
libcurl: 7.86.0 (sys:0.4.59+curl-7.86.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
os: Mac OS 13.2.1 [64-bit]
@conanoc conanoc added the C-bug Category: This is a bug. label Apr 10, 2023
@ehuss ehuss transferred this issue from rust-lang/cargo Apr 10, 2023
@ehuss
Copy link
Contributor

ehuss commented Apr 10, 2023

Transferred to rust-lang/rust, as cargo is not involved in linking.

@Jules-Bertholet
Copy link
Contributor

@rustbot label +A-linkage

@rustbot rustbot added the A-linkage Area: linking into static, shared libraries and binaries label Apr 26, 2023
@bjorn3
Copy link
Member

bjorn3 commented Oct 27, 2023

The whoami crate correctly added a dependency on the SystemConfiguration framework: https://github.com/ardaku/whoami/blob/1c076a5ac667c0258f9649efd346b238ab9c7b87/src/unix.rs#L82

The issue is that if you are building a staticlib, there is no way for the staticlib itself to define all dynamic libraries it depends on. As such you need to pass --print native-static-libs to rustc when compiling the staticlib and then use all the linker arguments it prints when linking against the staticlib. For example it could show:

note: Link against the following native artifacts when linking against this static library. The order and any duplication can be significant on some platforms.

note: native-static-libs: -lgcc_s -lutil -lrt -lpthread -lm -ldl -lc

in which case you have to pass -lgcc_s -lutil -lrt -lpthread -lm -ldl -lc to the linker when linking against the staticlib.

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 C-bug Category: This is a bug.
Projects
None yet
Development

No branches or pull requests

5 participants