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

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

Reproduce the macOS failure from the testcase using CC=clang/bin/clang cargo build, then compare the nightly builds from 2019-01-06 and 2019-01-07. Trace the cc build script and dynamic library resolution around the custom clang invocation; done means the crate builds successfully with the custom dynamically linked clang without the libLLVM.dylib symbol error.