Tracking Issue for linking modifiers for native libraries #81490
Comments
petrochenkov
added
the
C-tracking-issue
jonas-schievink
added
the
A-linkage
…trochenkov Implement RFC 2951: Native link modifiers A first attempt at implementing rust-lang/rfcs#2951 / rust-lang/compiler-team#356. Tracking Issue: rust-lang#81490 Introduces feature flags for the general syntax (`native_link_modifiers`) and each modifier (`native_link_modifiers_{as_needed,bundle,verbatim,whole_archive}`). r? `@petrochenkov`
…trochenkov Implement RFC 2951: Native link modifiers A first attempt at implementing rust-lang/rfcs#2951 / rust-lang/compiler-team#356. Tracking Issue: rust-lang#81490 Introduces feature flags for the general syntax (`native_link_modifiers`) and each modifier (`native_link_modifiers_{as_needed,bundle,verbatim,whole_archive}`). r? `@petrochenkov`
There are 4 feature gate: |
|
I don't think the incomplete warning is correct, the modifiers are not yet stable, but they are complete enough. |
remove native_link_modifiers from the list of incomplete features. These features are fully implemented and not incomplete. The tracking issue of them is rust-lang#81490. The implement PR is rust-lang#83507.
|
@petrochenkov Is there anything left before at least stabilizing the modifiers syntax (the |
|
No, as far as I know (I wanted to audit the implementation once more though). |
|
@petrochenkov I'm interested in helping out getting this stabilized if that's OK. Maybe: the Relative order of -l and -Clink-arg(s) options part of the RFC is not yet implemented: #83507 (comment). Is anyone working on it, otherwise does it sound reasonable for me to pick this up? |
|
@krasimirgg The "relative order" part is entirely orthogonal though, so you can certainly work on that. The code parsing these options ( |
|
I have a few clarifying questions if I may :)
Thanks! |
|
I now remember why I abandoned it. The linker command line is constructed in
So user options passed with So I guess the user options will have to be split into two groups now - "before the last |
For example, we can reuse the Then such args will always be ordered relatively to other |
|
@krasimirgg |
|
Stabilization PR for the |
|
We're seeing some issues with linker argument order for
I've prepared an example to illustrate the issue: https://github.com/krasimirgg/native-libs-order-example. With nightly rustc the linker reports a backward reference error of the bar rlib referring back to foo. The issue is that the With the old rustc behavior, these native libs were put in a To address this, would it make sense to update |
|
@krasimirgg The fix is (usually) to reorder the native libraries to respect dependencies between them, or (more rarely) to add a |
|
@petrochenkov I agree. This example is a bit different: there is just 1 native library and a reference from an rlib to it. The problem is with the relative order between an rlib and its native lib dependency. The general instance of this problem is something like: anytime something uses a picky linker with an rlib -> native dependency, they risk backward reference errors and will have to fall back to using In Bazel rules_rust, we currently have a knob to use We could update rules_rust to use an additional |
Nothing in https://github.com/krasimirgg/native-libs-order-example indicates that libbar.rlib depends on libfoo.a though. (*) This will result in UPD:
The |
Rustc is not the right abstraction level for that, IMO, since it's not aware of dependencies between libraries unless they are specified externally. |
|
Thank you very much! What I was missing was this way to instruct rustc to say an rlib depends on a native library at the time of building the rlib (with the -bundle modifier):
I think Bazel/rules_rust wasn't doing this properly in all cases, and because previously rustc was always using |
|
@petrochenkov I'm curious what's the mechanism via which rustc registers the dependency in this case:
Does it do it by recording some metadata in the rmeta rlib archive member? |
Yes. |
|
@petrochenkov : Consider a case where an rlib depends on multiple native libraries, which themselves depend on each other, say rlib Later, when |
Yes, in practice. |
Stabilize the `bundle` native library modifier And remove the legacy `static-nobundle` linking kind. Stabilization report - rust-lang#95818 (comment). cc rust-lang#81490 Closes rust-lang#37403
Stabilize the `bundle` native library modifier And remove the legacy `static-nobundle` linking kind. Stabilization report - rust-lang#95818 (comment). cc rust-lang#81490 Closes rust-lang#37403
Stabilize the `bundle` native library modifier And remove the legacy `static-nobundle` linking kind. Stabilization report - rust-lang#95818 (comment). cc rust-lang#81490 Closes rust-lang#37403
petrochenkov
added
the
T-compiler
|
Closing this umbrella issue in favor of more specific issues for the remaining unstable and unimplemented pieces:
|
|
For "Unresolved Questions" I think there is still the matter of the default of the |
|
@dcsommer |
Stabilize native library modifier `verbatim` Stabilization report - rust-lang#104360 (comment). cc rust-lang#81490 Closes rust-lang#99425
This is a tracking issue for the RFC "Linking modifiers for native libraries" (rust-lang/rfcs#2951) accepted through MCP rust-lang/compiler-team#356.
The feature gate for the issue is
#![feature(native_link_modifiers)].About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
whole-archivemodifier specifically reference#1170whole-archivemodifier specifically #93901Unresolved Questions
Implementation history
The text was updated successfully, but these errors were encountered: