Extend libtool RPATH outsmarting hack to external/librevenge

(See 1d028d4783da69c5c0e6e0b59e0f8ac55eb9d2b1 "Fix Linux RPATH of various
external modules" for the similar patches to other external projects.)  This is
a blind fix attempt for
<https://ci.libreoffice.org/job/lo_daily_update_gandalf/559/console>

> /lo/home/tdf/lode/jenkins/workspace/lo_daily_update_gandalf/instdir/program/librevenge-0.0-lo.so.0 has unexpected RPATH  0x000000000000001d (RUNPATH)            Library runpath: [/opt/rh/devtoolset-7/root/usr/lib/../lib64]
[...]
> /lo/home/tdf/lode/jenkins/workspace/lo_daily_update_gandalf/postprocess/CustomTarget_check_dynamic_objects.mk:20: recipe for target '/lo/home/tdf/lode/jenkins/workspace/lo_daily_update_gandalf/workdir/CustomTarget/postprocess/check_dynamic_objects/check.done' failed

after ed81fe44d4e6b36c4c61a22e9e28a3a94fef9238 "Enabling Developer Toolset 7 for
Jenkins' remaining GCC master jobs" enabled GCC 8 at gandalf's
/opt/rh/devtoolset-7/root/ (which is at the same location as a CentOS Developer
Toolset 7 special GCC 7, but is actually a plain GCC 8, cf.
<https://lists.freedesktop.org/archives/libreoffice/2018-December/081544.html>
"Re: Compiler baselines") for the lo_daily_update_gandalf job.  Presumably
libtool added to RPATH a path to find that GCC 8 installation's
/opt/rh/devtoolset-7/root/usr/lib64/libstdc++.so.6.

Change-Id: I18a88b2dcdfcaf2e2d36d5ee1b41ce865e4ac34e
Reviewed-on: https://gerrit.libreoffice.org/64943
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

0 files changed, 0 insertions, 0 deletions