Skip to content

building crate w/C library using custom, dynamically linked clang fails #6764

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Open
mykmelez opened this issue Mar 19, 2019 · 4 comments
Open
Labels
A-linkage Area: linker issues, dylib, cdylib, shared libraries, so A-links Area: `links` native library links setting C-bug Category: bug S-triage Status: This issue is waiting on initial triage.

Comments

@mykmelez
Copy link

Problem

Building a Rust crate containing a C library using a custom, dynamically-linked clang specified via the CC environment variable fails on macOS with a "symbol not found" error, apparently because the system loads libLLVM.dylib from the Rustup-installed toolchain rather than the custom installation:

cargo:warning=dyld: lazy symbol binding failed: Symbol not found: __ZN4llvm9DIBuilder17createCompileUnitEjPNS_6DIFileENS_9StringRefEbS3_jS3_NS_13DICompileUnit17DebugEmissionKindEybbb
cargo:warning= Referenced from: /Users/myk/rust-c-library-testcase/clang/bin/clang-7
cargo:warning= Expected in: /Users/myk/.rustup/toolchains/stable-x86_64-apple-darwin/lib/libLLVM.dylib

Steps

  1. Clone testcase repo:
    git clone https://github.com/mykmelez/rust-c-library-testcase.git && cd rust-c-library-testcase
  2. Install custom, dynamically-linked clang:
    curl -O https://taskcluster-artifacts.net/I36Um3guQMyU-HWz_tnG0Q/0/public/build/clang.tar.xz && tar xf clang.tar.xz
  3. Build crate with custom clang:
    CC=clang/bin/clang cargo build

Notes

Output of cargo version: cargo 1.33.0 (f099fe9 2019-02-12)

This appears to have regressed between Rust nightly build 2019-01-06 and 2019-01-07 (68fe5182c...b92552d55):

> cargo clean && CC=clang/bin/clang cargo +nightly-2019-01-06 build
Compiling cc v1.0.31
Compiling rust-c-library-testcase v0.1.0 (/Users/myk/rust-c-library-testcase)
Finished dev [unoptimized + debuginfo] target(s) in 1.93s
> cargo clean && CC=clang/bin/clang cargo +nightly-2019-01-07 build
Compiling cc v1.0.31
Compiling rust-c-library-testcase v0.1.0 (/Users/myk/rust-c-library-testcase)
error: failed to run custom build command for rust-c-library-testcase v0.1.0 (/Users/myk/rust-c-library-testcase)
process didn't exit successfully: /Users/myk/rust-c-library-testcase/target/debug/build/rust-c-library-testcase-166e0d070d05f6f9/build-script-build (exit code: 101)

See https://bugzilla.mozilla.org/show_bug.cgi?id=1536486 for an example of the issue in a project that uses a custom, dynamically-linked clang when building for Android targets.

@mykmelez mykmelez added the C-bug Category: bug label Mar 19, 2019
@ehuss
Copy link
Contributor

ehuss commented Mar 19, 2019

It's a long shot, but I'm curious, have you tried the latest nightly? There was a similar issue (rust-lang/rust#59034 (comment)) that was fixed a couple days ago (rust-lang/rust#59173).

@mykmelez
Copy link
Author

It's a long shot, but I'm curious, have you tried the latest nightly? There was a similar issue (rust-lang/rust#59034 (comment)) that was fixed a couple days ago (rust-lang/rust#59173).

Thanks for the tip! I updated to the latest nightly and can still reproduce the issue there:

> rustup update

stable-x86_64-apple-darwin unchanged - rustc 1.33.0 (2aa4c46cf 2019-02-28)
beta-x86_64-apple-darwin updated - rustc 1.34.0-beta.3 (7473869a6 2019-03-16)
nightly-x86_64-apple-darwin updated - rustc 1.35.0-nightly (0f88167f8 2019-03-18)

> CC=clang/bin/clang cargo +nightly build
Compiling cc v1.0.31
Compiling rust-c-library-testcase v0.1.0 (/Users/myk/rust-c-library-testcase)
error: failed to run custom build command for rust-c-library-testcase v0.1.0 (/Users/myk/rust-c-library-testcase)
process didn't exit successfully: /Users/myk/rust-c-library-testcase/target/debug/build/rust-c-library-testcase-4d3b681e42b21f8a/>build-script-build (exit code: 101)

@mykmelez
Copy link
Author

2019-01-06 only has one copy of libLLVM.dylib, while 2019-01-07 has two:

> find ~/.rustup/toolchains/nightly-2019-01-0[67]-x86_64-apple-darwin -name libLLVM.dylib
/Users/myk/.rustup/toolchains/nightly-2019-01-06-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libLLVM.dylib
/Users/myk/.rustup/toolchains/nightly-2019-01-07-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libLLVM.dylib
/Users/myk/.rustup/toolchains/nightly-2019-01-07-x86_64-apple-darwin/lib/libLLVM.dylib

The two are identical (and not hard or soft links):

> diff /Users/myk/.rustup/toolchains/nightly-2019-01-07-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libLLVM.dylib /Users/myk/.rustup/toolchains/nightly-2019-01-07-x86_64-apple-darwin/lib/libLLVM.dylib
> ls -lad /Users/myk/.rustup/toolchains/nightly-2019-01-07-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libLLVM.dylib /Users/myk/.rustup/toolchains/nightly-2019-01-07-x86_64-apple-darwin/lib/libLLVM.dylib
-rw-r--r-- 1 myk staff 58531716 Mar 19 14:04 /Users/myk/.rustup/toolchains/nightly-2019-01-07-x86_64-apple-darwin/lib/libLLVM.dylib
-rw-r--r-- 1 myk staff 58531716 Mar 19 14:04 /Users/myk/.rustup/toolchains/nightly-2019-01-07-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libLLVM.dylib

@emilio
Copy link

emilio commented Mar 20, 2019

Yeah, see rust-lang/rust#55737. Apparently the LLVM doesn't append the provided suffix on OSX.

@epage epage added S-triage Status: This issue is waiting on initial triage. A-linkage Area: linker issues, dylib, cdylib, shared libraries, so A-links Area: `links` native library links setting labels Oct 31, 2023
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-linkage Area: linker issues, dylib, cdylib, shared libraries, so A-links Area: `links` native library links setting C-bug Category: bug S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Development

No branches or pull requests

4 participants