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