-
Notifications
You must be signed in to change notification settings - Fork 13k
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
rustc_target: Remove pre_link_args_crt
#72782
Conversation
r? @varkor (rust_highfive has picked a reviewer for you, use r? to override) |
{ | ||
// FIXME: What this option does? Is it necessary given that we are already passing | ||
// `-static` and `-nodefaultlibs`? VxWorks GNU toolchain has no public documentation. | ||
self.cmd.arg("--static-crt"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@BaoshanPang @bpangWR @n-salim @UmeshKalappa, could you comment on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For VxWorks, we use "--static-crt" to tell the compiler driver that we want to use static C libraries no matter which kind of rust libraries will be used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@BaoshanPang
That's why I was mentioning -static
and -nodefaultlibs
, which rustc
passes to gcc-like linkers, in case of VxWorks as well.
How does wr-c++
interpret those options?
If it's gcc-compatible, I'd expect -nodefaultlibs
to remove libc from linking altogether and -static
to provide the desired "link everything statically" semantic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@BaoshanPang
One more question, since you added VxWorks support to https://github.com/rust-lang/libc as well.
Do I understand correctly that on VxWorks libc is linked into Rust programs due to this fallback clause?
https://github.com/rust-lang/libc/blob/master/src/unix/mod.rs#L351-L355
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait a second, was --static-crt
introduced to the wr-c++
driver for rustc
specifically by any chance?
To workaround the default behavior of #[link(name = "c")]
linking libc dynamically?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait a second, was
--static-crt
introduced to thewr-c++
driver forrustc
specifically by any chance?
To workaround the default behavior of#[link(name = "c")]
linking libc dynamically?
Yes, it was introduced for rustc. but it was not only for libc, it is also for only libraries used in VxWorks environement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@BaoshanPang
One more question, since you added VxWorks support to https://github.com/rust-lang/libc as well.
Do I understand correctly that on VxWorks libc is linked into Rust programs due to this fallback clause?
https://github.com/rust-lang/libc/blob/master/src/unix/mod.rs#L351-L355
No, I was not aware of this part when I added the code for rust libc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-static
to provide the desired "link everything statically" semantic.
One of the combination we want to support is shared rust library with static VxWorks C library.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@BaoshanPang
I see, thanks for the information!
I'll keep the current logic as is then, since I cannot test the changes myself.
However, the recommended way to link to libc, libpthread and similar system libraries is still through #[link]
attributes in https://github.com/rust-lang/libc, with cfg(target_feature = "crt-static")
being used for switching between dynamic and static linking.
See https://github.com/rust-lang/libc/blob/master/src/unix/mod.rs#L295-L357 for examples from other targets.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@BaoshanPang
I see, thanks for the information!
I'll keep the current logic as is then, since I cannot test the changes myself.However, the recommended way to link to libc, libpthread and similar system libraries is still through
#[link]
attributes in https://github.com/rust-lang/libc, withcfg(target_feature = "crt-static")
being used for switching between dynamic and static linking.
See https://github.com/rust-lang/libc/blob/master/src/unix/mod.rs#L295-L357 for examples from other targets.
Thanks for the information, We may use this solution for the next release.
Updated. |
@bors r+ rollup |
📌 Commit b628358 has been approved by |
Rollup of 6 pull requests Successful merges: - rust-lang#72718 (Add regression test for rust-lang#72554) - rust-lang#72782 (rustc_target: Remove `pre_link_args_crt`) - rust-lang#72923 (Improve E0433, so that it suggests missing imports) - rust-lang#72950 (fix `AdtDef` docs) - rust-lang#72951 (Add Camelid per request) - rust-lang#72964 (Bump libc dependency to latest version (0.2.71)) Failed merges: r? @ghost
To regain some more control over the definition of
+crt-static
(#71586).After #71769 this target option wasn't used anywhere except for VxWorks, and I suspect that for VxWorks its use may be redundant as well.