You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
As experiments in #94962 showed "never deduplicating" is also not a safe choice, because whole-archive libraries will produce errors if not deduplicated, and rustc has to use whole-archive by default in some cases, at least currently.
So I think we should use deduplication by default, especially given that currently things are "more deduplicated than not", but should not make this change until a stable dedup modifier is available to explicitly disable the deduplication when needed.
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.
or something.
We could potentially switch from the alternative 1 to alternative 2 on edition boundary if there's enough interest.
The text was updated successfully, but these errors were encountered: