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

[DRAFT] MSVC: Add msvc_crt_link options #3178

Closed
wants to merge 2 commits into from
Closed

Conversation

ChrisDenton
Copy link
Member

@ChrisDenton ChrisDenton commented Mar 30, 2023

Note
This only applies when libc is used as a dependency of std.

PR is for testing/discussion purposes only. It should not be merged yet.

See rust-lang/rust#39016 for more background

Currently libc hard codes the MSVC CRT that's used by the compiler. Users can select between two CRTs (dynamic and static) by toggling the target-feature=crt-static option. However, this is far from ideal given the number of possible configurations, especially when attempting to co-exist with existing C/C++ builds.

At a minimum, it's also useful to be able to use the debug or release versions of these libraries. The following table shows these possible combinations:

Release Debug
Dynamic msvcrt msvcrtd
Static libcmt libcmtd

Furthermore, users may want to disable linking the crt entirely so that they can fully control what is linked and how.

To support these different configurations, this PR adds a new cfg, msvc_crt_link=option, where option is the link configuration option. This can be set in global rustflags (using --cfg) so that it's applied consistently. The two possible options are:

  • debug: Use the debug versions of the CRT libraries
  • nocrt: disable all CRT linking. This obviously overrides all other options because nothing is linked

This allow configuring how the MSVC CRT is linked without involving the compiler.
@rustbot
Copy link
Collaborator

rustbot commented Mar 30, 2023

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

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

@JohnTitor
Copy link
Member

Triage: This has been open for more than six months. Is there anything I can help here?

@ChrisDenton
Copy link
Member Author

Hmm... I don't think so, I'd hoped this would be part of a wider discussion on solving the issue but that discussion doesn't look like it's going to happen any time soon. I'll remove this for now and maybe revisit if/when I can gather more interest. It is something that needs broader input so I wouldn't want to move forward without that.

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

Successfully merging this pull request may close these issues.

3 participants