[libc++] Do not define __muloti4 on Apple platforms

[ldionne]

Summary

The filesystem library defines muloti4 as a hack on platforms that do
not provide compiler_rt, and that do not define muloti4 as a result.
This is not the case on Apple platforms, and so we don't want libc++ to
define this symbol in that case.

Note that a less intrusive workaround for platforms that do not define
__muloti4 would be preferable.

[ldionne]

This patch is a not-so-great minimal fix for Apple platforms. @EricWF , if you have a suggestion of how to do this better (for example we could compile __muloti4 into a separate static archive and ship that on platforms that are not compiler_rt-based), feel free to suggest.

[ldionne]

I just noticed this was already handled by defining LIBCXX_USE_COMPILER_RT=ON in the CMake. Although I think the default should be LIBCXX_USE_COMPILER_RT=ON.

[EricWF]

Yeah, if we need to remove this symbol, I would just remove the source file from the build.

libcxx/src/filesystem/int128_builtins.cpp

  * FIXME: we steal and re-compile it into filesystem, which uses __int128_t,
  * and requires this builtin when sanitized. See llvm.org/PR30643
  *
  * ===----------------------------------------------------------------------===
  */
 #include "__config"
 #include "climits"
 
-#if !defined(_LIBCPP_HAS_NO_INT128)
+// Apple platforms provide compiler_rt, so there is no need to define __muloti4 here.
+#if !defined(__APPLE__)
+#  define _LIBCPP_DEFINE_MULOTI4_IN_DYLIB
+#endif
+
+#if !defined(_LIBCPP_HAS_NO_INT128) && defined(_LIBCPP_DEFINE_MULOTI4_IN_DYLIB)
 
 extern "C" __attribute__((no_sanitize("undefined")))
 __int128_t __muloti4(__int128_t a, __int128_t b, int* overflow) {
   const int N = (int)(sizeof(__int128_t) * CHAR_BIT);
   const __int128_t MIN = (__int128_t)1 << (N - 1);
   const __int128_t MAX = ~MIN;
   *overflow = 0;
   __int128_t result = a * b;