Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Add cargo:rustc-link-arg to pass custom linker arguments #6298
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.
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.
For posterity, there's more info on this in https://internals.rust-lang.org/t/pre-rfc-complete-cdylib-support-in-cargo/8843/12
Thanks, although I think there's still a number of open questions here:
The use-case I'm focusing is to pair it with a
from what I'm seeing for the
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.
referenced this pull request
Dec 10, 2018
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:
So all in all, the remaining items needed for this I think are:
I think I'd personally lean towards renaming this
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.