summaryrefslogtreecommitdiffstats
path: root/configure.ac
diff options
context:
space:
mode:
authorStephan Bergmann <sbergman@redhat.com>2016-09-23 09:03:49 +0200
committerStephan Bergmann <sbergman@redhat.com>2016-09-23 08:55:32 +0000
commit3a2818280ad65c3d0aa9e720f62fec571713b2e7 (patch)
treec29e451259cbaf94feb224133d684b5e3ae88096 /configure.ac
parentupload liblangtag 0.6.1 (diff)
downloadcore-3a2818280ad65c3d0aa9e720f62fec571713b2e7.tar.gz
core-3a2818280ad65c3d0aa9e720f62fec571713b2e7.zip
external/liblangtag: Tunnel LD_LIBRARY_PATH to where it's actually needed
At least make-4.1-5.fc24.x86_64's /usr/bin/make (indirectly) links against libfreebl3.so, so it could erroneously pick up our instdir/program/libfreebl3.so delivered there from external/nss. But that's a problem for ASan/UBSan builds, where that libfreebl3.so is instrumented and expects to find certain symbols exported from the executable (and which /usr/bin/make of course doesn't have), so running make from within external/liblangtag/ExternalProject_langtag.mk fails. Turns out that the only place where LD_LIBRARY_PATH is needed during the build of external/liblangtag is when running workdir/UnpackedTarget/langtag/data/reg2xml. (This is unrelated to the recent changes to external/liblangtag by the way; just happend to show up now by accident, when doing an incremental build where external/nss had already been built when external/liblangtag got rebuilt. external/firebird has a similar problem, but everybody seems to run ASan/UBSan builds with --disable-firebird-sdbc anyway for now.) Change-Id: I6e045b6d33a154e350f4640265e6568f96634187 Reviewed-on: https://gerrit.libreoffice.org/29211 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
Diffstat (limited to 'configure.ac')
0 files changed, 0 insertions, 0 deletions