Add cargo:rustc-link-arg to pass custom linker arguments

[lu-zero]

It is useful to produce correct cdylibs on platforms such as Linux and
MacOS.

Groundwork to address #5045 in the future.

[alexcrichton]

Thanks for the PR! I'm personally a bit wary to add this though without more protections and/or safeguards. In addition to the soft feature freeze this is a feature we have intentionally not added historically as it can be tricky to do so.

I would personally prefer at least that this takes the route of a more formal feature proposal such as a discussion on internals or a mini-rfc.

[lu-zero]

If you have time to guide me on that I'm more than willing to :)

Keep in mind that we have an env key that already let you pass those values, but it does to all the rustc invocations and my actual need is to pass the right linker flags so the soname is set for cdylibs.

We can restrict it to just cdylibs or just make cargo come up with the os-specific incantations at least for the tier1 platforms.

[alexcrichton]

For posterity, there's more info on this in https://internals.rust-lang.org/t/pre-rfc-complete-cdylib-support-in-cargo/8843/12

[bors]

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

[lu-zero]

Here an attempt on restricting, not sure where is the best place to error out if somebody mixes cdylib and dylib.

[alexcrichton]

Thanks, although I think there's still a number of open questions here:

• Currently this is ignoring link-args on non-cdylib crates (silently), is that the behavior that we want?
• What happens if there's mutliple crate types, where do the link args go?
• Do we want to read this from .cargo/config? Is there a use case for that?

[lu-zero]

Thanks, although I think there's still a number of open questions here:

* Currently this is ignoring link-args on non-cdylib crates (silently), is that the behavior that we want?

The use-case I'm focusing is to pair it with a build.rs providing the link lines. So non-cdylib or non-cdylib+staticlib could be an hard error.

* What happens if there's mutliple crate types, where do the link args go?

from what I'm seeing for the cdylib+staticlib case it works as expected even if rustc is called only once.

* Do we want to read this from `.cargo/config`? Is there a use case for that?

For my usecase there isn't.

On the other hand this can be reused by cargo-deb/rpm/ebuild later for their distro-specific purposes (e.g. custom rpaths), but I'd rather not conflate it.

[bors]

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

[alexcrichton]

Sorry for having this fall by the wayside, this fell off my radar by accident!

@lu-zero would you still be willing to help drive this PR forward?

Following up with some of my questions above, for cases where the link-args aren't used I don't really know what the best answer is. I think it's fine for now though to swallow them and document that we swallow them, and if it becomes an issue we can issue warnings or something like that later.

For the many crate types, we probably want to either:

• Pass the link args to all linked artifacts (except maybe tests)
• Rename these to rustc-cdylib-link-arg or somethig like that (to make it clear it only applies to cdylib and leave space to customize them in the future)

For .cargo/config what I meant was that you can specify build script outputs in .cargo/config in native library overrides. I think I missed though where this was already handled.

So all in all, the remaining items needed for this I think are:

• Documentation for this new feature
• Decision on where to route link args for multiple artifact (aka ignore for all but cdylib or rename to say it's only going to cdylib)

I think I'd personally lean towards renaming this rustc-cdylib-link-arg which leaves us room to add more flavorful configuration for other output artifacts in the future. For example we could have a mode where you specify binary link args but only for one binary and not others.

[lu-zero]

@lu-zero would you still be willing to help drive this PR forward?

Sure. I'll update the PR during the weekend :)

[alexcrichton]

Ok sounds great, and sorry again for the delay!

[lu-zero]

I renamed the key, regarding the documentation to update, where I should I find it?

[alexcrichton]

@rfcbot fcp merge

Ok! This looks great to me, so I'd like to propose that this be merged, but would also like to get a signoff from the rest of the team.

[rfcbot]

Team member @alexcrichton has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Eh2406
• @alexcrichton
• @dwijnand
• @ehuss
• @joshtriplett
• @nrc
• @withoutboats
• @wycats

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[joshtriplett]

I personally would like this (and would use this) for binaries, not just cdylib, but cdylib certainly helps.

[lu-zero]

I'd relax the constraint later and land it sooner if possible :)

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[alexcrichton]

@bors: r+

[bors]

📌 Commit f608ed6 has been approved by alexcrichton

[bors]

⌛️ Testing commit f608ed6 with merge 5f3f281...

[bors]

☀️ Test successful - checks-travis, status-appveyor
Approved by: alexcrichton
Pushing 5f3f281 to master...