[PATCH] D129142: [LLD][ELF] Drop duplicates from rpath

[Fangrui Song via Phabricator via llvm-commits]

MaskRay added a comment.

In D129142#3632403 <https://reviews.llvm.org/D129142#3632403>, @sberg wrote:

> In D129142#3631968 <https://reviews.llvm.org/D129142#3631968>, @sberg wrote:
>
>> In D129142#3631781 <https://reviews.llvm.org/D129142#3631781>, @MaskRay wrote:
>>
>>> This GNU ld behavior is surprising (deviating from how options are usually handled, e.g. `--auxiliary a --auxiliary b`) and not matching it does not actually cause a problem to reasonable users.
>>
>> But still, both ld.bdf and ld.gold have code to explicitly prune such duplicate -rpath arguments (see the code pointers in the summary).  So even though neither of those two linkers appears to give a rationale for that behavior, it nevertheless appears to be a deliberate decision to behave that way.  I asked for a rationale now at https://sourceware.org/pipermail/binutils/2022-July/121626.html "Deliberate deduplication of -rpath arguments in ld.bfd and ld.gold?"
>
> Quoting the answer at https://sourceware.org/pipermail/binutils/2022-July/121628.html "Re. Deliberate deduplication of -rpath arguments in ld.bfd and ld.gold?":
>
>> The rationale would be "avoid waste in the real world".  If you don't do that then you will find that when building certain software it will end up with hundreds of copies of things like "RUNPATH /usr/lib/my-strange-module-path/" because its build-system is strange, and blindly collects linker arguments from e.g. pkg-config files, but doesn't remove duplicates itself.  As the runtime linker doesn't do duplicate removal either (speed!) it would then end up looking into loading the same non-existing file that same hundred times.
>> Instead of fixing all these build systems, something simply has to remove the duplicates and the linker is the most sensible choice.

Note that the argument isn't very strong and is more about the behavior may provide a benefit and "since ld does this for so long, we just keep the behavior".
But this is not sufficient to add the inconsistency/complexity to another linker when there is really no behavior difference.
I think losing the strictness is a shame in this particular case as doesn't seem to cause problems in the wild.
LibreOffice likely should fix its build system instead.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129142/new/

https://reviews.llvm.org/D129142