> Date: Sat, 27 Oct 2018 10:00:01 +0200 > From: Sebastien Marie <sema...@online.fr> > > Hi, > > I am sending this email on tech@, as I assume it could be interesting > for base developers to be aware of a slightly difference between ld.bfd > and ld.lld regarding -rpath option (and as I sent a previous mail on > ports@ and not everybody follow ports@). > > while I investigated a problem on productivity/glabels (see ports@ about > glabels/libtool) I found a difference in rpath management. As it could > be tricky, I prefer to report it to people most aware than me in the > difference. > > The short story is: > $ ld.lld -rpath=value => Add a DT_RUNPATH to the output. > $ ld.bfd -rpath=value => Add a DT_RPATH to the output. > > >From ld.so comments, I think it isn't a problem as it seems just be the > library path search order that could changed a bit. > > libexec/ld.so/library_subr.c > > * Otherwise, the name doesn't contain a '/': > * search hints for the specific library version, trying in turn > * paths from the following: > * - the LD_LIBRARY_PATH environment variable (if set) > * - the library's own DT_RUNPATH > * - if DT_RUNPATH wasn't set, then: > * - the library's own DT_RPATH > * - the executable's own DT_RPATH > * - the default search path set by ldconfig, or /usr/lib if unset > > But in case it could be a bit more complex... I prefer to let people > know. > > Regarding productivity/glabels, it is us base libtool that doesn't > manage DT_RUNPATH but only DT_RPATH for retrieving library path (a diff > has been provided on ports@). > > Thanks.
Correct. More recent GNU linkers behave the same way as lld, which is why I think the change in behaviour is a good thing. It is possible to make ld.lld emit DT_RPATH by passing -Wl,-disable-new-dtags. And if you pass -Wl,-enable-new-dtags, our ld.bfd will emit DT_RUNPATH (although it will also emit DT_RPATH in that case). Maybe we should revisit the defaults for ld.bfd on this.
