rustc_target: Remove pre_link_args_crt#72782
Conversation
|
r? @varkor (rust_highfive has picked a reviewer for you, use r? to override) |
There was a problem hiding this comment.
@BaoshanPang @bpangWR @n-salim @UmeshKalappa, could you comment on this?
There was a problem hiding this comment.
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.
@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.
@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.
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.
Wait a second, was
--static-crtintroduced to thewr-c++driver forrustcspecifically 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.
@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.
-staticto 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.
@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.
@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.