mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-10-09 11:25:00 +00:00
c5caa62fdf
Build slaves on automation are based on Centos 6, which doesn't have a recent enough version of libstdc++ for our new requirements. But since we're building with a recent GCC or clang with its own libstdc++, we do have such a libstdc++ available somewhere, and the compiler picks it when invoking the linker. Problems start happening when we execute some of the built programs during the build, like host tools (e.g. nsinstall), or target programs (xpcshell, during packaging). In that case, we need the compiler's libstdc++ to be used. Which required adding the GCC or clang library directory to LD_LIBRARY_PATH. Unconveniently enough, the clang 3.5 tooltool package we're using for ASAN builds until we can update to at least 3.8 (bug 1278718) doesn't contain libstdc++.so. So for those builds, pull the GCC package from tooltool as well, and pick libstdc++ from there.
16 lines
695 B
Plaintext
16 lines
695 B
Plaintext
# Avoid dependency on libstdc++ 4.7
|
|
ac_add_options --enable-stdcxx-compat
|
|
|
|
TOOLTOOL_DIR=${TOOLTOOL_DIR:-$topsrcdir}
|
|
|
|
if [ -f "$TOOLTOOL_DIR/clang/lib/libstdc++.so" ]; then
|
|
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}$TOOLTOOL_DIR/clang/lib
|
|
elif [ -f "$TOOLTOOL_DIR/gcc/lib/libstdc++.so" ]; then
|
|
# We put both 32-bits and 64-bits library path in LD_LIBRARY_PATH: ld.so
|
|
# will prefer the files in the 32-bits path when loading 32-bits executables,
|
|
# and the files in the 64-bits path when loading 64-bits executables.
|
|
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}$TOOLTOOL_DIR/gcc/lib64:$TOOLTOOL_DIR/gcc/lib
|
|
fi
|
|
|
|
mk_add_options "export LD_LIBRARY_PATH=$LD_LIBRARY_PATH"
|