external/nss: Fix rpath for Linux et al

See CustomTarget_postprocess/check_dynamic_objects (in a
--with-package-format=... build) failing after
8512f4ca090c85477a6670438aeefe7fdfcf8a98 "build nss using their new build system
(gyp/ninja-based)" with

> instdir/program/libsmime3.so has no RPATH
> instdir/program/libnssutil3.so has no RPATH
> instdir/program/libnssdbm3.so has no RPATH
> instdir/program/libfreeblpriv3.so has no RPATH
> instdir/program/libsqlite3.so has no RPATH
> instdir/program/libfreebl3.so has no RPATH
> instdir/program/libnssckbi.so has no RPATH
> instdir/program/libnss3.so has no RPATH
> instdir/program/libsoftokn3.so has no RPATH
> instdir/program/libssl3.so has no RPATH

workdir/UnpackedTarball/gyp/pylib/gyp/generator/ninja.py already has logic to
add -Wl,-rpath=$ORIGIN/... to certain link command lines, presumably for
building certain executables, but of which we apparently include none in
ExternalPackage_nss, so it shouldn't hurt to keep them using that other
-Wl,-rpath=$ORIGIN/...  I have no idea whether there would be a cleaner way than
this patch to pass an additional -Wl,-rpath=$ORIGIN to all link command lines
via the invocation of build.sh in ExternalProject_nss (even if those executables
mentioned in the previous sentence would then have two -Wl,-rpath=..., that
should not hurt in practice).

(Most, if not all of the rpath-related hunks of external/nss/nss.patch that were
needed for the make-based nss build on Linux et al prior to
8512f4ca090c85477a6670438aeefe7fdfcf8a98 can probably be removed in a follow-up
commit.)

Change-Id: I65eaf52efeb6feceb8540e0aedf340f9a9a18599
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91012
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

0 files changed, 0 insertions, 0 deletions