[PATCH] D64427: LLVM Test-Suite: Support Cross-Compilation and Cross-execution targeting arm64-linux-android

Stephen Hines via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jul 12 03:41:25 PDT 2019


srhines added inline comments.


================
Comment at: cmake/caches/target-arm64-android-template.sh:32
+-D BIONIC_IOCTL_NO_SIGNEDNESS_OVERLOAD \
+-L $ANDROID_NDK_LOCATION/toolchains/llvm/prebuilt/$HOST_SYSTEM/lib/gcc/aarch64-linux-android/4.9.x/"
+
----------------
danalbert wrote:
> pcc wrote:
> > danalbert wrote:
> > > This is needed because the compiler being used isn't the NDK toolchain, right? It's just the bare compiler without the sysroot and all that? If so, you *might* be able to use `-gcc-toolchain $ANDROID_NDK_LOCATION/toolchains/llvm/prebuilt/$HOST_SYSTEM` instead of specifying the internal location of libgcc. (If not, fixing the driver to make that work would probably be good)
> > What I usually do is: `-B${ANDROID_NDK_PATH}/toolchains/llvm/prebuilt/linux-x86_64`.
> > 
> > Would it be worth considering moving libgcc.a into the sysroot in a future release of the NDK? Then I believe only `--sysroot` should be required.
> Maybe. I was somewhat trying to keep toolchain components separate from the platform APIs, but that's not really that important in this case since that's a fairly blurry line anyway. On the other hand, we're hopefully switching to libclangrt_builtins soon anyway, so maybe not worth the effort for either.
Unfortunately, libgcc.a is here to stay until the Android unwinder can be used as part of the builtins. I don't think that is considered a high priority though. I would prefer that libgcc.a exist somewhere better in the NFL, considering we could drop the rest of the GCC dirs if we do that.


Repository:
  rT test-suite

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

https://reviews.llvm.org/D64427





More information about the llvm-commits mailing list