Plugin silently ignored if only found as an rlib

[huonw]

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

extern crate rustc;

use rustc::plugin::Registry;
#[plugin_registrar]
pub fn plugin_registrar(_: &mut Registry) {
    println!("registering!");
}

// plugin_user.rs
#![feature(phase)]
#[phase(plugin)] extern crate plugin;

fn main() {}

$ # only .so
$ rustc --crate-type dylib plugin.rs && rustc plugin_user.rs -L .
registering!

$ # both .so and .rlib
$ rustc --crate-type rlib plugin.rs && rustc plugin_user.rs -L .
registering!

$ # only .rlib
$ rm libplugin*.so
$ rustc plugin_user.rs -L .

(i.e. no output for the last one: the plugin isn't loaded.)

[netvl]

I've stumbled upon this right now. A cargo project which depends on a crate which export plugins will fail to compile if these plugins/macros are used.
BTW, because cargo only compiles dependencies as rlibs, this issue breaks any builds which use exported plugins from external crates, and there is no direct workaround as far as I can see except from manually compiling all affected dependencies.

[huonw]

@netvl that's where I met it too, but does the dependency have the following?

[[lib]]
...
crate_type = ["dylib"]

[netvl]

It's funny, but it does now :) the author was quick to fix it to use dylib for now. With updated dependency it works fine, though the binary became dynamically linked, naturally.

[huonw]

the binary became dynamically linked, naturally

Yes, macro crates should be separate to the core functionality for now (e.g. how quickcheck is organised), to avoid forcing the syntax and rustc dependencies on the downstream crates, and to avoid forcing dynamic linkage.