flexible target specification breaks plugins lookup

[farcaller]

I've got two crates failing to build after flexible target specification (6b130e3) was merged.

rustc \
  --opt-level 2 \
  -Z no-landing-pads \
  --cfg mcu_k20 --cfg arch_cortex_m4 \
  -g \
  -C no-stack-check \
  -L /Users/farcaller/src/zinc/build \
  --out-dir /Users/farcaller/src/zinc/build \
  /Users/farcaller/src/zinc/src/macro/ioreg.rs

builds libmacro_ioreg.dylib (and a matching libmacro_ioreg.dylib.dSYM).

The crate that depends on it fails to build though:

rustc \
  --opt-level 2 \
  -Z no-landing-pads \
  --cfg mcu_k20 --cfg arch_cortex_m4 \
  --target thumbv7em-none-eabi -Ctarget-cpu=cortex-m4 \
  -C relocation_model=static \
  -g \
  -C no-stack-check \
  -L /Users/farcaller/src/zinc/build \
  --out-dir /Users/farcaller/src/zinc/build  /Users/farcaller/src/zinc/src/zinc/lib.rs
/Users/farcaller/src/zinc/src/zinc/lib.rs:52:18: 52:43 error: can't find crate for `macro_ioreg`
/Users/farcaller/src/zinc/src/zinc/lib.rs:52 #[phase(plugin)] extern crate macro_ioreg;
                                                              ^~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error

if I remove --target thumbv7em-none-eabi, the macro_ioreg crate is resolved correctly.

target spec:

{
    "data-layout": "e-m:e-p:32:32-i1:8:32-i8:8:32-i16:16:32-i64:64-v128:64:128-a:0:32-n32-S64",
    "llvm-target": "thumbv7em-none-eabi",
    "target-endian": "little",
    "target-word-size": "32",
    "arch": "arm",
    "os": "none",
    "morestack": false
}

[farcaller]

I think this is the relevant log chunk:

DEBUG:rustc::metadata::creader: resolving extern crate stmt. ident: macro_ioreg path_opt: None
DEBUG:syntax::attr: attr::contains_name (name=link)
DEBUG:syntax::attr:   testing: plugin
DEBUG:rustc::metadata::filesearch: using sysroot = /usr/local, triple = x86_64-apple-darwin
DEBUG:rustc::metadata::filesearch: filesearch: searching additional lib search paths [1]
DEBUG:rustc::metadata::filesearch: searching /Users/farcaller/src/zinc/build
...
DEBUG:rustc::metadata::filesearch: testing /Users/farcaller/src/zinc/build/libmacro_ioreg.dylib
DEBUG:rustc::metadata::filesearch: rejected /Users/farcaller/src/zinc/build/libmacro_ioreg.dylib

[farcaller]

Update: this happens only on Win and OS X hosts; compiling from linux is fine.

[emberian]

@farcaller could I bother you to try and reproduce this now? I don't have Win/OS X right now, unfortunately.

[farcaller]

Still there as of 5484d6f. I've been doing a bit of debugging on this one yesterday but didn't really progress any further.

[farcaller]

Okay, I finally got down to exact problem which is this codepath in metadata loader:

        if triple != self.triple {
            info!("Rejecting via crate triple: expected {} got {}", self.triple, triple);
            self.rejected_via_triple.push(CrateMismatch {
                path: libpath.clone(),
                got: triple.to_string()
            });
            return false;
        }

failing with Rejecting via crate triple: expected thumbv7m-none-eabi got x86_64-apple-darwin.

honestly speaking I have not a single idea why this is working on linux 😄 it should be broken literally everywhere.

The problem here is that triple should be checked against rustc's current platform triple, not target triple in case of plugins.

[bgamari]

I am able to reproduce this on Linux with rustc 1.0.0-dev (6a697325c 2015-01-09 18:56:14 -0500)

[larsbergstrom]

@alexcrichton @brson I suspect this is the issue that had been breaking our Servo OSX->Android builds for the past couple of months, and am very afraid that it will break both our Linux Android and Gonk builds when we get whatever causes this to break Linux as well and block our upgrade to 1.0 alpha

[alexcrichton]

@farcaller, @bgamari, @larsbergstrom, is there a small code example that I could reproduce this behavior with?

[farcaller]

plugin.rs:

#![feature(plugin_registrar)]
#![crate_type="dylib"]

#[macro_use] extern crate log;
extern crate rustc;

use rustc::plugin::Registry;

#[plugin_registrar]
pub fn plugin_registrar(reg: &mut Registry) {
  info!("plugin registrar called");
}

main.rs:

#![feature(plugin)]
#![crate_type="staticlib"]

#[plugin] extern crate plugin;

% rustc plugin.rs
...
% rustc main.rs -L . --target arm-unknown-linux-gnueabi
main.rs:4:11: 4:31 error: can't find crate for `plugin`
main.rs:4 #[plugin] extern crate plugin;
                    ^~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error