[libcxx-commits] [PATCH] D78787: [libcxx][libcxxabi][libunwind] Use libgcc on Android

[Ryan Prichard via Phabricator via libcxx-commits]

rprichard added a comment.

I suppose this change is probably OK. I don't think it will affect the Android organization, because I don't think we're using the CMake files for libc++/libc++abi/libunwind yet. I think we'll start using libunwind's CMake files soon.

Android doesn't ever use libgcc_s. We're trying to remove our use of libgcc and replace it with compiler-rt and libunwind.

It seems that these macros are used to determine which libraries to link into libc++/libc++abi/libunwind, which only matters when the output is a shared library? libc++ is the only one that the Android platform or NDK builds as a shared library. Our libc++[_shared].so always has libc++abi linked statically. For the default platform builds, we currently link against the unwinder from libc.so, but otherwise (for the NDK and for some APEXs), we link an unwinder into libc++[_shared].so statically. (If we move to using libc++[_shared].so from the Android toolchain build, we'll need three different outputs?)

Aside: On my gLinux/Debian system, it appears that libgcc.a doesn't have an unwinder in it. Instead, the unwinder is in libgcc_eh.a or libgcc_s.so.1. libgcc_s.so is a text file that pulls in libgcc_s.so.1 and libgcc.a.

Also, libcxxabi is detecting libgcc by looking for an ARM EABI symbol. Should that be something architecture-independent instead?

  check_library_exists(gcc __aeabi_uldivmod "" LIBCXXABI_HAS_GCC_LIB)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D78787/new/

https://reviews.llvm.org/D78787