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

Stephan Bergmann via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jul 6 05:29:01 PDT 2022


sberg added a comment.

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.




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

https://reviews.llvm.org/D129142



More information about the llvm-commits mailing list