Bug 1278456 - Add the tooltool GCC library directory to LD_LIBRARY_PATH on Linux builds. r=mshal
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.
2016-06-07 04:50:36 +00:00
|
|
|
# Avoid dependency on libstdc++ 4.7
|
|
|
|
|
ac_add_options --enable-stdcxx-compat
|
|
|
|
|
|
|
|
|
|
TOOLTOOL_DIR=${TOOLTOOL_DIR:-$topsrcdir}
|
|
|
|
|
|
2017-05-16 06:09:52 +00:00
|
|
|
if [ -f "$TOOLTOOL_DIR/gcc/lib/libstdc++.so" ]; then
|
Bug 1278456 - Add the tooltool GCC library directory to LD_LIBRARY_PATH on Linux builds. r=mshal
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.
2016-06-07 04:50:36 +00:00
|
|
|
# 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
|
2017-05-16 06:09:52 +00:00
|
|
|
elif [ -f "$TOOLTOOL_DIR/clang/lib/libstdc++.so" ]; then
|
|
|
|
|
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}$TOOLTOOL_DIR/clang/lib
|
Bug 1278456 - Add the tooltool GCC library directory to LD_LIBRARY_PATH on Linux builds. r=mshal
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.
2016-06-07 04:50:36 +00:00
|
|
|
fi
|
|
|
|
|
|
|
|
|
|
mk_add_options "export LD_LIBRARY_PATH=$LD_LIBRARY_PATH"
|
