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 07:50:36 +03:00
|
|
|
# Avoid dependency on libstdc++ 4.7
|
2017-12-21 05:13:08 +03:00
|
|
|
export MOZ_STDCXX_COMPAT=1
|
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 07:50:36 +03:00
|
|
|
|
|
|
|
|
TOOLTOOL_DIR=${TOOLTOOL_DIR:-$topsrcdir}
|
|
|
|
|
|
2017-12-29 09:16:45 +03:00
|
|
|
# Depending whether GCC was built on a RedHat-based or a Debian-based system,
|
|
|
|
|
# the directory containing 32-bits libraries can be either (respectively)
|
|
|
|
|
# lib or lib32. The directory for 64-bits libraries is always lib64.
|
|
|
|
|
if [ -f "$TOOLTOOL_DIR/gcc/lib64/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 07:50:36 +03: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.
|
2017-12-29 09:16:45 +03:00
|
|
|
# We also put both possible 32-bits library paths.
|
|
|
|
|
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}$TOOLTOOL_DIR/gcc/lib64:$TOOLTOOL_DIR/gcc/lib32:$TOOLTOOL_DIR/gcc/lib
|
2017-05-16 09:09:52 +03: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 07:50:36 +03:00
|
|
|
fi
|
|
|
|
|
|
|
|
|
|
mk_add_options "export LD_LIBRARY_PATH=$LD_LIBRARY_PATH"
|
