Build fails on -musl targets because of proc_macro

[drozdziak1]

Hi there,
I'm cross-building (OpenWrt with musl, nightly from 2018-01-09) a package that indirectly depends on this crate. Unfortunately the build fails due to the crate proc_macro missing. AFAIK this is due to a Rust compiler gimmick but I'm not sure how to approach this problem. I've got a couple questions:

• Do you happen to know the root cause of this issue?
• Is there a solution out there? If so, what is it?
• If not, what can I do to help resolve it?

I'd really appreciate your thoughts on this.

Thank you,
Stanisław

[alexcrichton]

Yes unfortunately this can't be solved in the near future, you'll want to be sure that when cross-compiling you're not enabling the nightly feature of this crate. In general this crate is mostly intended to go into procedural macros instead of applications/libraries (especially if nightly is enabled)

[mystor]

@alexcrichton Unfortunately I'm pretty sure it also doesn't work without nightly enabled, because we link to proc_macro unconditionally, and proc_macro is a dynamic library.

The best solution for now is probably to add a proc_macro feature which governs whether or not that crate is linked in. The longer term solution is probably to, in rustc, make proc_macro a static library, and move procedural macros out of process or something similar to that.

[alexcrichton]

Oh oops right! Forgot that there were stable things in proc_macro...

In that case yeah, let's have an on-by-default feature for that perhaps?

[mystor]

Yeah, I think that's probably the best option we've got right now.

Technically a breaking change for anyone using --no-default-features though.

[drozdziak1]

Thanks for casting some light on this. I'll see what the status quo is in rustc. Is there any workaround I can introduce in a fork of this repo and the dependent crates in my project?

[alexcrichton]

@drozdziak1 maybe this documentation will help?

Also out of curiosity, what's your use case for using the proc-macro2 crate on musl?

[drozdziak1]

@alexcrichton Thank you! I'm sure this will come in handy

I'm working on Althea, an incentivized mesh network project. We're building a router firmware using OpenWrt and we're using Rust for the most part. My role was to set up a package definition in OpenWrt to cross-build our Rust binaries and it was going pretty well when this issue creeped out. AFAIR it was serde that was dependent on this crate.

OpenWrt itself uses musl by default but we're also considering switching our targets to glibc to work around this. The problem is, OpenWrt crashes somewhere else when we do that in build config and at the moment we're still weighing our options. Personally, I'd prefer to fix this on Rust side since musl is smaller than glibc. It makes a lot of sense especially given the executable size of Rust programs and limited resources of embedded devices.

[alexcrichton]

@drozdziak1 hm are you parsing Rust code on the device itself? If not this may be a mistake actually, serde itself doesn't link to proc-macro2 at runtime, just serde_derive at compile time.

Do you have a way to reproduce this error?

[drozdziak1]

It's pretty convoluted to reproduce. But from what cargo tree tells me it seems that your crate isn't in our dependency tree anymore (could be an error though)

[alexcrichton]

@drozdziak1 it may be due to this perhaps?

[drozdziak1]

@alexcrichton Yeah, but serde depends on it (on quote)

[alexcrichton]

@drozdziak1 I think serde_derive does but serde shouldn't. What happens if you try to remove that crate annotation?

[dtolnay]

The released version of serde_derive depends on quote but not on a version of quote that depends on proc_macro. Are you sure the problematic dependency on proc_macro is through quote?

[drozdziak1]

@dtonlay This is the serde part of cargo tree: http://www60.zippyshare.com/v/n5Nvqyxi/file.html

[drozdziak1]

I think it used to show proc-macro2 somewhere down this subtree a couple days ago. But I'm starting to think this cargo tree thing might be broken because even though I grep proc-macro2 I can't find it anywhere in the dependency tree. But when I try to build it's the proc-macro2 crate that gets listed as failed

[drozdziak1]

I'm using a workspace in my package and also some dependencies have their version unspecified (*). Maybe the package version compromise resolution in cargo for workspaces is messing this up. I'm currently going the glibc route but I'll also check on this front.

[drozdziak1]

Okay. I've seen many things and read a lot of docs. Why doesn't this crate specify proc-macro = true?

[alexcrichton]

@drozdziak1 the proc-macro = true marker is for procedural macros (the end crate), this crate's just an rlib which is a dependency of procedural macros.

[drozdziak1]

@alexcrichton But doesn't using proc_macro mean your crate has to be a proc_macro one i.e. a dynamically linked library which is only used at compile time? (IIUC that's what this states https://doc.rust-lang.org/unstable-book/language-features/proc-macro.html)

[alexcrichton]

@drozdziak1 I'm getting sort of lost in this and I'm not sure it's going anywhere. Is there still a bug for you? Did removing the linkage to quote work?