Adding upstream version 115.7.0esr.upstream/115.7.0esr

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 117 insertions, 0 deletions

diff --git a/build/autoconf/toolchain.m4 b/build/autoconf/toolchain.m4
new file mode 100644
index 0000000000..270738f4d5
--- /dev/null
+++ b/build/autoconf/toolchain.m4
@@ -0,0 +1,117 @@
+dnl This Source Code Form is subject to the terms of the Mozilla Public
+dnl License, v. 2.0. If a copy of the MPL was not distributed with this
+dnl file, You can obtain one at http://mozilla.org/MPL/2.0/.
+
+dnl Several autoconf functions AC_REQUIRE AC_PROG_CPP/AC_PROG_CXXCPP
+dnl or AC_HEADER_STDC, meaning they are called even when we don't call
+dnl them explicitly.
+dnl However, theses checks are not necessary and python configure sets
+dnl the corresponding variables already, so just skip those tests
+dnl entirely.
+define([AC_PROG_CPP],[])
+define([AC_PROG_CXXCPP],[])
+define([AC_HEADER_STDC], [])
+
+dnl AC_LANG_* set ac_link to the C/C++ compiler, which works fine with
+dnl gcc and clang, but not great with clang-cl, where the build system
+dnl currently expects to run the linker independently. So LDFLAGS are not
+dnl really adapted to be used with clang-cl, which then proceeds to
+dnl execute link.exe rather than lld-link.exe.
+dnl So when the compiler is clang-cl, we modify ac_link to use a separate
+dnl linker call.
+define([_MOZ_AC_LANG_C], defn([AC_LANG_C]))
+define([AC_LANG_C],
+[_MOZ_AC_LANG_C
+if test "$CC_TYPE" = "clang-cl"; then
+  ac_link="$ac_compile"' && ${LINKER} -OUT:conftest${ac_exeext} $LDFLAGS conftest.obj $LIBS 1>&AC_FD_CC'
+fi
+])
+
+define([_MOZ_AC_LANG_CPLUSPLUS], defn([AC_LANG_CPLUSPLUS]))
+define([AC_LANG_CPLUSPLUS],
+[_MOZ_AC_LANG_CPLUSPLUS
+if test "$CC_TYPE" = "clang-cl"; then
+  ac_link="$ac_compile"' && ${LINKER} -OUT:conftest${ac_exeext} $LDFLAGS conftest.obj $LIBS 1>&AC_FD_CC'
+fi
+])
+
+AC_DEFUN([MOZ_TOOL_VARIABLES],
+[
+GNU_CC=
+GNU_CXX=
+if test "$CC_TYPE" = "gcc"; then
+    GNU_CC=1
+    GNU_CXX=1
+fi
+
+CLANG_CC=
+CLANG_CXX=
+CLANG_CL=
+if test "$CC_TYPE" = "clang"; then
+    GNU_CC=1
+    GNU_CXX=1
+    CLANG_CC=1
+    CLANG_CXX=1
+fi
+if test "$CC_TYPE" = "clang-cl"; then
+    CLANG_CL=1
+fi
+
+AC_SUBST(CLANG_CXX)
+AC_SUBST(CLANG_CL)
+])
+
+AC_DEFUN([MOZ_CROSS_COMPILER],
+[
+echo "cross compiling from $host to $target"
+
+dnl AC_CHECK_PROGS manually goes through $PATH, and as such fails to handle
+dnl absolute or relative paths. Relative paths wouldn't work anyways, but
+dnl absolute paths would. Trick AC_CHECK_PROGS into working in that case by
+dnl adding / to PATH. This is temporary until this moves to moz.configure
+dnl (soon).
+_SAVE_PATH=$PATH
+case "${TOOLCHAIN_PREFIX}" in
+/*)
+    PATH="/:$PATH"
+    ;;
+esac
+AC_PROG_CC
+AC_PROG_CXX
+
+PATH=$_SAVE_PATH
+])
+
+AC_DEFUN([MOZ_CXX11],
+[
+dnl Updates to the test below should be duplicated further below for the
+dnl cross-compiling case.
+AC_LANG_CPLUSPLUS
+if test "$GNU_CXX"; then
+    AC_CACHE_CHECK([whether 64-bits std::atomic requires -latomic],
+        ac_cv_needs_atomic,
+        AC_TRY_LINK(
+            [#include <cstdint>
+             #include <atomic>],
+            [ std::atomic<uint64_t> foo; foo = 1; ],
+            ac_cv_needs_atomic=no,
+            _SAVE_LIBS="$LIBS"
+            LIBS="$LIBS -latomic"
+            AC_TRY_LINK(
+                [#include <cstdint>
+                 #include <atomic>],
+                [ std::atomic<uint64_t> foo; foo = 1; ],
+                ac_cv_needs_atomic=yes,
+                ac_cv_needs_atomic="do not know; assuming no")
+            LIBS="$_SAVE_LIBS"
+        )
+    )
+    if test "$ac_cv_needs_atomic" = yes; then
+      MOZ_NEEDS_LIBATOMIC=1
+    else
+      MOZ_NEEDS_LIBATOMIC=
+    fi
+    AC_SUBST(MOZ_NEEDS_LIBATOMIC)
+fi
+AC_LANG_C
+])