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. -- Sebastien Marie
