Use cfg_attr to gate musl linking

[Others]

Fixes #684. Previously building libc for musl would fail, because we don't want to use #[link(...)] outside a stdbuild. This commit fixes that issue. (Although it may leave other targets broken, I'm not sure.)

[alexcrichton]

Looks like CI is failing? Can you also include tests from #685?

[Others]

@alexcrichton I'm already seeing more failures on travis, even with the style fix. I think this is mostly because we never want to issue a link when stdbuild is not enabled. How would you feel about gating all the link pragmas behind stdbuild? One way of doing that would be changing:

else if #[cfg(all(not(stdbuild), feature = "use_std"))] {

To:

else if #[cfg(any(not(stdbuild), feature = "use_std"))] {

[Others]

Alternatively I can just introduce a fix for the rumprun target (which looks to be the only broken one), and leave the rest as-is.

[alexcrichton]

Ah yeah it'd be great to add this same fix there as well!

[Others]

@alexcrichton Okay, I've made the CI build work for all platforms. I did, however, use the first method I outlined and prevent any linking from happening if not(stdbuild). I think that the logic is cleaner this way--and could prevent future issues.

If you agree with the above assessment, then I think this is ready to be merged.

[alexcrichton]

Hm yeah so the only gotcha there is that if you pull in the libc crate without the standard library you may get unresolved symbol errors. Is that the use case you have in mind or is libstd still pulled in elsewhere?

[Others]

@alexcrichton Yeah, you're right. Fixing it this way won't work. But I don't think the earlier #[cfg_attr(...)] fix works either. (Since it prevents the necessary libc.a from being pulled in on musl if you aren't using the standard library.)

I'm not sure how to proceed here. Do you know of any other options we have?

[alexcrichton]

It's true yeah, we could avoid the cfg inside the link attribute perhaps though? Basically have a #[cfg_attr(not(stdbuild), link(...))]?

[Others]

@alexcrichton How can we avoid the cfg inside the link? Don't we want different behavior depending on whether target_feature = "crt-static"?

[alexcrichton]

Yeah we wouldn't get precisely the same behavior, we'd have to select one kind of linakge for musl, for example.

[Others]

@alexcrichton Do you have any thoughts on what we should do then? #684 is a serious problem for using Rust on a MUSL platform. If there is no quick fix for now, perhaps we should introduce some sort of work around?

[alexcrichton]

I think our only option is to have #[link(name = "c")] and pray it works.

[clarfonthey]

Is there any progress on this? I'd be willing to help out with a fix but I'm not sure where to go from here.

[Others]

@clarcharr I'm still paying attention to this, although I've been busy at work this past week. I'm dissatisfied with the current solution / every solution outlined thus far. I feel like the #[link(name = "c")]approach is likely to break -crt-static linking (which I personally depend on). @alexcrichton do you have further thoughts on this? Do you want me to just forge ahead with the #[link(name = "c")] and pray strategy?

[alexcrichton]

Ideally this would look like:

#[cfg_attr(all(not(stdbuild), target_feature = "crt-static"), link(name = "c", kind = "static")]
#[cfg_attr(all(not(stdbuild), not(target_feature = "crt-static")), link(name = "c")]

But right now target_feature = "crt-static" is unstable to match against. Short of that I'm not entirely sure what to do.

[bors]

☔ The latest upstream changes (presumably #734) made this pull request unmergeable. Please resolve the merge conflicts.

[alexcrichton]

I'm going to close this due to inactivity, but feel free to resubmit with a rebase!