Plugin symbol resolution errors with i686 compiler

[huonw]

// plugin.rs
#![feature(plugin_registrar, rustc_private)]

extern crate rustc;

#[plugin_registrar]
pub fn plugin_registrar(reg: &mut rustc::plugin::Registry) {}

fn wrap_item(x: Option<u8>) {
    x.expect("");
}

// foo.rs
#![feature(plugin)]
#![plugin(plugin)]

fn main() {}

This fails to build:

$ rustc plugin.rs --crate-type dylib &&  rustc foo.rs -L .
plugin.rs:6:25: 6:28 warning: unused variable: `reg`, #[warn(unused_variables)] on by default
plugin.rs:6 pub fn plugin_registrar(reg: &mut rustc::plugin::Registry) {}
                                    ^~~
plugin.rs:8:1: 10:2 warning: function is never used: `wrap_item`, #[warn(dead_code)] on by default
plugin.rs: 8 fn wrap_item(x: Option<u8>) {
plugin.rs: 9     x.expect("");
plugin.rs:10 }
foo.rs:2:11: 2:17 error: .../libplugin.so: undefined symbol: _ZN6option13_$LT$impl$GT$6expect10_FILE_LINE20h69e9aacc3131c4bbR2ME
foo.rs:2 #![plugin(plugin)]
                   ^~~~~~

NB. I'm on an x86-64 computer, but I installed and am running a i686 compiler via multirust:

$ multirust update nightly-i686 --installer https://static.rust-lang.org/dist/rust-nightly-i686-unknown-linux-gnu.tar.gz
$ multirust default nightly-i686

It also failed on Travis, where the i686 installer is downloaded and installed manually. I guess this may be some issue with how multirust/that installation works.

[alexcrichton]

This looks like it's because the host libs are different from the target libs (in theory shouldn't ever happen).

Possible cause: the i686 libstd package is actually a bunch of libraries produced by a x86_64 compiler, it may be the case that the symbols or something along the line is dependent on the architecture that produced the artifact. The i686 host libs, however, are produced by an i686 compiler.

I think due to the way hashing works the same library compiled by an i686 compiler vs x86_64 compiler (even if for the same target) will produce different binaries (causing the discrepancy here).

This... seems like we should be more picky about picking libs to ship!