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 relocation-model option to build profiles #1909

Closed
wants to merge 2 commits into from

Conversation

worr
Copy link

@worr worr commented Aug 17, 2015

rustc has an option to change the way symbol relocation happens at compile
time. While the default of pic is often preferred, there are some cases where
a user may need to output an object where the symbols are non-relocatable
(some kernels, for instance).

Expose the relocation-model argument to the user through the profiles stanza
in Cargo.toml.

rustc has an option to change the way symbol relocation happens at compile
time. While the default of pic is often preferred, there are some cases where
a user may need to output an object where the symbols are non-relocatable
(some kernels, for instance).

Expose the relocation-model argument to the user through the profiles stanza
in Cargo.toml.
@rust-highfive
Copy link

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @wycats (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

In addition to being able to specify how symbols relocations are handled, it's
also useful for some projects to be able to specify different outputs for
rustc to emit (asm, obj, etc.). Add an additional profile field to control
that as well.
@alexcrichton
Copy link
Member

Thanks for the PR! Currently, however, the goal of the profiles in Cargo isn't necessarily to reexport every codegen option of the compiler at the top level (also see #1137). Something like relocation-model which is required to build a project has been thought to belong in the custom target JSON instead of in the manifest perhaps.

That being said, this is an open design question of how to reexport various options like these, and for now I'd prefer to avoid adding new options without exploring the design space a bit more. As a result I'm going to close this for now. I think we'll probably want something like an RFC to move forward here rather than design-via-PR, so feel free to reach out to me on IRC! (acrichto)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants