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

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jul 6 00:25:18 PDT 2022


MaskRay added a comment.

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

> In D129142#3631741 <https://reviews.llvm.org/D129142#3631741>, @MaskRay wrote:
>
>> I did not mean this behavior. I mean whether this complexity brings anything beneficial. I don't think the runtime behavior is affected.
>> Put it another way: is this change necessary.
>
> Ah.  The way I came across this is that LibreOffice has some check to make sure that certain of its shared libraries on Linux have a DT_RUNPATH of exactly `$ORIGIN`.  And one of its (bundled external) libraries, built through some libtool invocation, where the LibreOffice build system passes it some `LDFLAGS=-Wl,-rpath,$ORIGIN`, happened to end up with two such `-Wl,-rpath,$ORIGIN` on the libtool command line, so when built with lld had a DT_RUNPATH of `$ORIGIN:$ORIGIN`, so the check for exactly `$ORIGIN` failed.
>
> So while this shouldn't affect runtime behavior of the resulting object, it was a divergence from GNU behavior that got in the way for me.

OK. Then it seems like a problem in LibreOffice. It passes two `-rpath` and then has a brittle assumption that `-rpath` is deduplicated.
lld has always been behaving this way and there are users linking LibreOffice with lld fine, so I am unsure porting this surprising behavior is necessary.
Technically the increased complexity isn't that high (4 lines) but the justification does not seem strong enough.


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

https://reviews.llvm.org/D129142



More information about the llvm-commits mailing list