Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 5 commits into
base: master
from

Conversation

Projects
None yet
5 participants
@lu-zero
Copy link

lu-zero commented Nov 9, 2018

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

Groundwork to address #5045 in the future.

@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented Nov 12, 2018

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

This comment has been minimized.

Copy link
Author

lu-zero commented Nov 12, 2018

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

This comment has been minimized.

Copy link
Member

alexcrichton commented Nov 18, 2018

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Nov 18, 2018

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

@lu-zero lu-zero force-pushed the lu-zero:rustc-link-args branch from fd3e037 to 104b861 Nov 18, 2018

@lu-zero

This comment has been minimized.

Copy link
Author

lu-zero commented Nov 18, 2018

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

@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented Nov 21, 2018

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

This comment has been minimized.

Copy link
Author

lu-zero commented Nov 21, 2018

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

This comment has been minimized.

Copy link
Contributor

bors commented Nov 28, 2018

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

@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented Mar 8, 2019

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

This comment has been minimized.

Copy link
Author

lu-zero commented Mar 8, 2019

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

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

@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented Mar 8, 2019

Ok sounds great, and sorry again for the delay!

@lu-zero lu-zero force-pushed the lu-zero:rustc-link-args branch from 104b861 to 9741016 Mar 8, 2019

@lu-zero

This comment has been minimized.

Copy link
Author

lu-zero commented Mar 8, 2019

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

@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented Mar 11, 2019

@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

This comment has been minimized.

Copy link
Collaborator

rfcbot commented Mar 11, 2019

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

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

This comment has been minimized.

Copy link
Member

joshtriplett commented Mar 11, 2019

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

@lu-zero

This comment has been minimized.

Copy link
Author

lu-zero commented Mar 19, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.