Skip to content

Tracking Issue for linking modifiers for native libraries  #81490

New issue
New issue
Closed
Closed
Tracking Issue for linking modifiers for native libraries #81490
Assignees
petrochenkov
Labels
A-linkageArea: linking into static, shared libraries and binariesC-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

Description

@petrochenkov
petrochenkov
opened on Jan 28, 2021

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

Unresolved Questions

Implementation history

Activity

  1. Imagepetrochenkov
    added
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    on Jan 28, 2021
  2. Imagejonas-schievink
    added
    A-linkageArea: linking into static, shared libraries and binaries
    on Jan 28, 2021
  3. Imagepetrochenkov
    self-assigned this
    on Feb 7, 2021
  4. ImageDylan-DPC-zz
    added 2 commits that reference this issue on May 5, 2021

    Rollup merge of rust-lang#83507 - luqmana:native-link-modifiers, r=pe…

    2d9234e

    Rollup merge of rust-lang#83507 - luqmana:native-link-modifiers, r=pe…

    5dcdeb8

  5. 12101111 commented on May 23, 2021

    @12101111
    12101111
    on May 23, 2021
    Contributor
    warning: the feature `native_link_modifiers` is incomplete and may not be safe to use and/or cause compiler crashes
 --> library/unwind/src/lib.rs:8:12
  |
8 | #![feature(native_link_modifiers)]
  |            ^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(incomplete_features)]` on by default
  = note: see issue #81490 <https://github.com/rust-lang/rust/issues/81490> for more information

    There are 4 feature gate: native_link_modifiers_{as_needed,bundle,verbatim,whole_archive}, are they both incomplete or just some of them are incomplete?

  6. petrochenkov commented on May 23, 2021

    @petrochenkov
    petrochenkov
    on May 23, 2021
    ContributorAuthor

    I don't think the incomplete warning is correct, the modifiers are not yet stable, but they are complete enough.

  7. Imagebors
    added a commit that references this issue on May 23, 2021

    Auto merge of rust-lang#85606 - 12101111:link_modifiers, r=petrochenkov

    9f69e2f

  8. luqmana commented on Sep 10, 2021

    @luqmana
    luqmana
    on Sep 10, 2021
    Contributor

    @petrochenkov Is there anything left before at least stabilizing the modifiers syntax (the native_link_modifiers feature)? If not I can help move that forward. It's definitely something we need to do before we stabilize any of the specific formats.

  9. petrochenkov commented on Sep 10, 2021

    @petrochenkov
    petrochenkov
    on Sep 10, 2021
    ContributorAuthor

    No, as far as I know (I wanted to audit the implementation once more though).
    It probably makes sense to stabilize the syntax together with one of the specific modifiers, otherwise the stabilization is all the responsibility and none of the profits.

  10. krasimirgg commented on Feb 10, 2022

    @krasimirgg
    krasimirgg
    on Feb 10, 2022
    Contributor

    @petrochenkov I'm interested in helping out getting this stabilized if that's OK.
    I'm hoping this RFC will help us improve Bazel Rust support.
    I'm a novice with respect to rustc development.
    What's left and what's the best way to get involved?

    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?

  11. petrochenkov commented on Feb 10, 2022

    @petrochenkov
    petrochenkov
    on Feb 10, 2022
    ContributorAuthor

    @krasimirgg
    I actually just started auditing the implementation for stabilization today (the general modifier syntax, and the whole-archive modifier specifically). If no other task interrupts me, then I'll likely make a PR tomorrow.

    The "relative order" part is entirely orthogonal though, so you can certainly work on that.
    I remember starting implementing that and discovering that it is a more invasive change than I expected, so I abandoned it due to a lack of time, IIRC.

    The code parsing these options (-l, -C link-arg and -C link-args) lives in compiler\rustc_session\src\options.rs and in compiler\rustc_session\src\config.rs.
    It currently builds two separate option vectors - Options::libs and CodegenOptions::link_args, instead it needs to build a single vector for the both kinds of options that will then be used throughout the compiler.

  12. hlopko commented on Feb 11, 2022

    @hlopko
    hlopko
    on Feb 11, 2022
    Contributor

    I have a few clarifying questions if I may :)

    1. So the stabilization of modifiers is orthogonal to the relative order fix?

    2. Should we still reference the same RFC for the work?

    3. Should we guard the new behavior of the relative order fix behind an experimental flag? Or see it as a bugfix and change the default behavior of the compiler?

    Thanks!

  13. petrochenkov commented on Feb 11, 2022

    @petrochenkov
    petrochenkov
    on Feb 11, 2022
    ContributorAuthor

    @hlopko

    1. Yes.
    2. Yes.
    3. No, probably not, I see it as a bugfix. See below.

  14. 21 remaining items

  15. krasimirgg commented on May 9, 2022

    @krasimirgg
    krasimirgg
    on May 9, 2022
    Contributor

    @petrochenkov : Consider a case where an rlib depends on multiple native libraries, which themselves depend on each other, say rlib r depends on libnative1.a which itself depends on libnative2.a. My understanding is that while building r, we'll supply its native dependencies in the expected relative linker order, e.g., rustc -o r.rlib ... -lstatic:-bundle=native1 -lstatic:-bundle=native2 ....

    Later, when r is used to build a rust binary b, I'd expect that in the linker invocation constructed to build b, the relative order of native1 and native2 will be preserved. Does rustc guarantee that?

  16. petrochenkov commented on May 9, 2022

    @petrochenkov
    petrochenkov
    on May 9, 2022
    ContributorAuthor

    @krasimirgg

    I'd expect that in the linker invocation constructed to build b, the relative order of native1 and native2 will be preserved. Does rustc guarantee that?

    Yes, in practice.
    See #96328 for some discussion about documenting it.

  17. ImageDylan-DPC
    added a commit that references this issue on May 31, 2022

    Rollup merge of rust-lang#95818 - petrochenkov:stabundle, r=wesleywiser

    bcdd8bd
  18. ImageDylan-DPC
    added a commit that references this issue on Jun 10, 2022

    Rollup merge of rust-lang#95818 - petrochenkov:stabundle, r=wesleywiser

    12063f4
  19. Imagebors
    added a commit that references this issue on Jun 10, 2022

    Auto merge of rust-lang#95818 - petrochenkov:stabundle, r=wesleywiser

    3dea003
  20. Imagepetrochenkov
    added
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    on Jul 18, 2022

  21. petrochenkov commented on Jul 18, 2022

    @petrochenkov
    petrochenkov
    on Jul 18, 2022
    ContributorAuthor

    Closing this umbrella issue in favor of more specific issues for the remaining unstable and unimplemented pieces:

  22. Imagepetrochenkov
    closed this as completedon Jul 18, 2022

  23. dcsommer commented on Aug 2, 2022

    @dcsommer
    dcsommer
    on Aug 2, 2022
    Contributor

    For "Unresolved Questions" I think there is still the matter of the default of the bundle link modifier and it's purpose and interaction with respect to whole-archive. The full cross-product of intended behaviors for (+/-whole-archive, +/-bundle, crate-type) is a little unclear to me and would ideally get documentation.

  24. petrochenkov commented on Aug 2, 2022

    @petrochenkov
    petrochenkov
    on Aug 2, 2022
    ContributorAuthor

    @dcsommer
    This is already documented in beta/nightly docs - https://doc.rust-lang.org/beta/rustc/command-line-arguments.html
    Except that the compatibility case for whole-archive is intentionally vague, and the restriction on +bundle,+whole-archive in rlibs in not documented because it's sort of an implementation deficiency that we are planning to fix (#99429).

  25. ImageDylan-DPC
    added a commit that references this issue on Nov 28, 2022

    Rollup merge of rust-lang#104360 - petrochenkov:stabverb, r=TaKO8Ki

    f33d409
  26. Imagechristian-schilling
    added 2 commits that reference this issue on Jan 27, 2026

    Rollup merge of #83507 - luqmana:native-link-modifiers, r=petrochenkov

    c9db0bd

    Rollup merge of #83507 - luqmana:native-link-modifiers, r=petrochenkov

    654445f
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

A-linkageArea: linking into static, shared libraries and binariesC-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions