Skip to content

Linked native libraries are sometimes deduplicated and sometimes not deduplicated #73319

Open
@petrochenkov

Description

@petrochenkov

The approximate rule is that deduplication happens when -l options on command line are involved (which override or not override #[link] attributes) and don't happen when only #[link] attributes are involved.
I don't want to get into the details here because I plan to fix this myself in some near future, but I'll perhaps extend it if the plan fails.

#47989 raised this issue previously and #57018 changed the rules in this area somewhat, and the PR author was lucky to get the desired linking order after the changes, but someone else could be less lucky and get broken order instead.

What could be a correct solution to this issue:

  • Never deduplicate.
    Safe choice, but may result in some redundant libraries passed to the linker.
    Library renaming will still work (#[link(name = "zoo")] + -lfoo -lzoo:myzoo -> -lmyzoo -lfoo -lmyzoo) but will pass one potentially redundant linker option.
    (There are alternatives, e.g. consider options with :renames "directives" rather than libraries and remove them after applying the renaming.)

  • Always deduplicate, but provide an opt-out for cases when an option/attribute must not be deduplicated.
    The non-deduplicatable cases should be pretty rare after all.

    #[link(name = "foo", modifiers = "-dedup")]
    

    or something.

We could potentially switch from the alternative 1 to alternative 2 on edition boundary if there's enough interest.

Metadata

Metadata

Assignees

Labels

A-linkageArea: linking into static, shared libraries and binariesC-bugCategory: This is a bug.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions