ICE while attempting to resolve against symlinked rlibs

[davidzchen]

I am working on adding Rust support to Bazel. I encountered an ICE when running rustc while building a crate where the following are true:

• The dependency search directory contains symlinks to rlibs.
• The crate builds against a native library.

In this case, I am building time using the following command:

RUST_BACKTRACE=1 rustc third_party/time/upstream/src/lib.rs \
    --crate-name time \
    --crate-type lib \
    -g \
    --out-dir bazel-out/local_darwin-fastbuild/bin/third_party/time \
    --emit=dep-info,link \
    -L dependency=bazel-out/local_darwin-fastbuild/bin/third_party/time/time.deps \
    --extern libc=bazel-out/local_darwin-fastbuild/bin/third_party/time/time.deps/liblibc.rlib \
    -L native=bazel-out/local_darwin-fastbuild/bin/third_party/time \
    -l static=time_helpers

where the bazel-out/local_darwin-fastbuild/bin/third_party/time directory contains the following:

❯❯❯ tree bazel-out/local_darwin-fastbuild/bin/third_party/time
bazel-out/local_darwin-fastbuild/bin/third_party/time
├── libtime_helpers.a
├── time.deps
│   └── liblibc.rlib -> bazel-out/local_darwin-fastbuild/bin/third_party/libc/liblibc.rlib
└── time_helpers.o

1 directory, 3 files

The main difference between this rustc command and the one that Cargo runs for time is that the dependencies directory here contains symlinks to the rlibs.

Running the above rustc command results in the following ICE:

error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
thread 'rustc' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Os(2) }', /Users/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-mac/build/src/libcore/result.rs:729

stack backtrace:
   1:        0x10d5a67b5 - sys::backtrace::write::hb40a7a5e7a72988bfas
   2:        0x10d5af3f0 - panicking::on_panic::h86479ea026bd45advvw
   3:        0x10d569918 - rt::unwind::begin_unwind_inner::h293827e692145ff2Ndw
   4:        0x10d56a71c - rt::unwind::begin_unwind_fmt::h50405e2d93950933Tcw
   5:        0x10d5aef4c - rust_begin_unwind
   6:        0x10d603cb5 - panicking::panic_fmt::he351326af800e539i5B
   7:        0x10a904d91 - metadata::filesearch::FileSearch<'a>::search::closure.97164
   8:        0x10a8fd8d1 - metadata::loader::Context<'a>::find_library_crate::hc625a239a9e69b38BAn
   9:        0x10a8f43f1 - metadata::loader::Context<'a>::load_library_crate::h2b8fdcb6c721cdabtpn
  10:        0x10a8f0d0b - metadata::creader::CrateReader<'a>::resolve_crate::h18d5732dcf682201Gam
  11:        0x10a8f4874 - metadata::creader::CrateReader<'a>::resolve_crate_deps::closure.96703
  12:        0x10a8f46cf - collections::hash::map::HashMap<K, V, S>.FromIterator<(K, V)>::from_iter::h11512003508812104640
  13:        0x10a8f27d8 - metadata::creader::CrateReader<'a>::register_crate::he08e6ccfd18bb940e8l
  14:        0x10a8f0dfc - metadata::creader::CrateReader<'a>::resolve_crate::h18d5732dcf682201Gam
  15:        0x10a8f4874 - metadata::creader::CrateReader<'a>::resolve_crate_deps::closure.96703
  16:        0x10a8f46cf - collections::hash::map::HashMap<K, V, S>.FromIterator<(K, V)>::from_iter::h11512003508812104640
  17:        0x10a8f27d8 - metadata::creader::CrateReader<'a>::register_crate::he08e6ccfd18bb940e8l
  18:        0x10a8f0dfc - metadata::creader::CrateReader<'a>::resolve_crate::h18d5732dcf682201Gam
  19:        0x10a8f4874 - metadata::creader::CrateReader<'a>::resolve_crate_deps::closure.96703
  20:        0x10a8f46cf - collections::hash::map::HashMap<K, V, S>.FromIterator<(K, V)>::from_iter::h11512003508812104640
  21:        0x10a8f27d8 - metadata::creader::CrateReader<'a>::register_crate::he08e6ccfd18bb940e8l
  22:        0x10a8f50b5 - metadata::creader::CrateReader<'a>::read_extension_crate::h34f09d139d38ed648fm
  23:        0x10a8f732c - metadata::creader::CrateReader<'a>::read_exported_macros::h0922848be3b977a72jm
  24:        0x10a9117f5 - metadata::macro_import::MacroLoader<'a>.Visitor<'v>::visit_item::ha40d7fd63402ea0fuSo
  25:        0x10a91085a - metadata::macro_import::read_macro_defs::h2a6bab7ef80e90a6gRo
  26:        0x109c2e06e - driver::phase_2_configure_and_expand::h23847d975e8fb38aYsa
  27:        0x109c20279 - driver::compile_input::heb62e3ff94a6164dQba
  28:        0x109cdbe54 - run_compiler::h16134909dfe8b0c9n6b
  29:        0x109cd95aa - boxed::F.FnBox<A>::call_box::h14102854404630110502
  30:        0x109cd8cc7 - rt::unwind::try::try_fn::h12738087818574960391
  31:        0x10d637bf8 - rust_try_inner
  32:        0x10d637be5 - rust_try
  33:        0x10d599315 - rt::unwind::try::inner_try::h8724f7b732bcbc52G9v
  34:        0x109cd8f22 - boxed::F.FnBox<A>::call_box::h14615098147423876694
  35:        0x10d5adeed - sys::thread::Thread::new::thread_start::h4c9197fb4b3ddc8afyv
  36:     0x7fff875c0267 - _pthread_body
  37:     0x7fff875c01e4 - _pthread_start

From what I understand, this panic is caused by some file not being found when resolving crates (hence the Os(2) result). It appears to me that the file that FileSearch is unable to find is the libc rlib due to liblibc.rlib being a symlink in the search directory, especially since if I remove the symlink and copy liblibc.rlib into bazel-out/local_darwin-fastbuild/bin/third_party/time/time.deps/, the rustc command runs just fine.

What's also curious is that when I build other crates that have dependencies but do not link native libraries, such as url, rustc is able to resolve the crates without any issues, even though they are symlinked.

Output of rustc --version --verbose:

❯❯❯ rustc --version --verbose
rustc 1.2.0-nightly (613e57b44 2015-06-01) (built 2015-06-01)
binary: rustc
commit-hash: 613e57b448c88591b6076a8cea9799f1f3876687
commit-date: 2015-06-01
build-date: 2015-06-01
host: x86_64-apple-darwin
release: 1.2.0-nightly

This also reproduces on 1.0.0 stable.

[alexcrichton]

I am working on adding Rust support to Bazel.

Whoa, awesome!

where the bazel-out/local_darwin-fastbuild/bin/third_party/time directory contains the following:

Isn't the liblibc.rlib rlib symlink an invalid symlink? It's valid relative to the root, but the symlink I believe is resolved relative to where the symlink is located.

Running the above rustc command results in the following ICE:

This is a bug regardless!

[nagisa]

Could reproduce. I think I found the issue, waiting for compile.

[davidzchen]

It's valid relative to the root, but the symlink I believe is resolved relative to where the symlink is located.

Ah, that solves the problem. Many other Bazel mechanisms reference files relative to the workspace root, but in this case, the symlink is indeed resolved relative to the directory where the symlink is located. Thanks for the catch!

This is a bug regardless!

Could reproduce. I think I found the issue, waiting for compile.

Thanks for looking into this so quickly!