Skip to content

Explicit support for whole-archive linker option #7586

@leeopop

Description

@leeopop
  1. The problem

Some libraries using __attribute__((constructor)) suffers when their libraries are not linked via whole-archive linker option.
However, current cargo build script does not support this functionality.

  1. Alternatives

We may use RUSTFLAGS option to give custom linker option, however I expect that this is not a desired use case of cargo.

whole-archive is not needed when dynamically loading a shared library.
(the loader explicitly invoke the constructor function)
(in static linking case, linker finds no explicit linkage so that the library is omitted)

  1. Solution

Add another link type to cargo's link-lib list.
Currently, we have static, dylib, and framework.
As whole-archive works on static linking case, we may name it as static-whole.

e.g. cargo:rustc-link-lib=static-whole=foo at the build script.

I'm aware of the risk when the linker flag is fully open.
I expect that this is the reason why linker flags are not open to build scripts.
Thus, I suggest to explicit support a single type of linking: static-whole along with other specialized link types.

  1. Implementation strategy

Cargo internally manages the static-whole database.
At the final linking state, cargo opens a whole-archive, listing all static-whole libraries from the depending crates, and closes whole-archive.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-linkageArea: linker issues, dylib, cdylib, shared libraries, soC-feature-requestCategory: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions