Building NDK 21 on macOS failed with libatomic related issues

[Naville Zhang]

Following up the issue at GitHub: https://github.com/android/ndk/issues/1575

I've tried commenting out code in build.py that's related to setting CMAKE_C/CXX_COMPILER, but the compilation process still halts when building compiler-rt due to lacking some declaration in std:: namespace, and the compiler used to build compiler-rt is still not the stock Clang provided by Xcode.

Of course, I could just build clang out-of-tree using the traditional LLVM CMake commands, but I'd rather build the whole NDK and ran NDK's own test suite, if possible

Zhang

[Pirama Arumuga Nainar]

Looks like you are on MacOS 11.3:

> -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk

This particular version was built on MacOS 10.13.  It is possible that this old toolchain doesn't build on a newer MacOS/XCode.

I also checked build.py for this manifest and we don't set -isysroot for this version (we had a major rewrite of the build scripts last year).  Try setting the additional variables at https://android.googlesource.com/toolchain/llvm_android/+/master/base_builders.py#218.

--
You received this message because you are subscribed to the Google Groups "android-llvm" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-llvm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-llvm/9f7b97ac-5eef-4311-ac13-67c259f3eaf4n%40googlegroups.com.

[Stephen Hines]

I tried a local build on my upgraded Mac, and also hit a build failure, so perhaps there is something more wrong here with the r365631 build on newer Macos versions. Pirama, are you suggesting that we're using the wrong `-isysroot`? There appear to be 2 instances of this, and just looking at my Mac install, there is only that 1 .sdk directory structure available (i.e. I don't have anything for older SDKs).

Steve

FAILED: /Volumes/Android/srhines/aosp-llvm-r365631/out/stage2/./bin/clang++   -DHAVE_RPC_XDR_H=0 -I/Volumes/Android/srhines/aosp-llvm-r365631/toolchain/llvm-project/compiler-rt/lib/sanitizer_common/.. -Wall -std=c++11 -Wno-unused-parameter -O3 -DNDEBUG -arch arm64 -arch x86_64 -arch x86_64h -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk    -stdlib=libc++ -mmacosx-version-min=10.9 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk -fPIC -fno-builtin -fno-exceptions -funwind-tables -fno-stack-protector -fno-sanitize=safe-stack -fvisibility=hidden -fno-lto -O3 -gline-tables-only -Wno-gnu -Wno-variadic-macros -Wno-c99-extensions -Wno-non-virtual-dtor -fno-rtti -Wframe-larger-than=570 -Wglobal-constructors -DSANITIZER_SUPPORTS_WEAK_HOOKS=0 -MD -MT lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoHooks.osx.dir/sanitizer_platform_limits_posix.cc.o -MF lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoHooks.osx.dir/sanitizer_platform_limits_posix.cc.o.d -o lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoHooks.osx.dir/sanitizer_platform_limits_posix.cc.o -c /Volumes/Android/srhines/aosp-llvm-r365631/toolchain/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.cc
/Volumes/Android/srhines/aosp-llvm-r365631/toolchain/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.cc:169:31: error: invalid application of 'sizeof' to an incomplete type 'struct stat64'
  unsigned struct_stat64_sz = sizeof(struct stat64);
                              ^     ~~~~~~~~~~~~~~~
/Volumes/Android/srhines/aosp-llvm-r365631/toolchain/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.cc:169:45: note: forward declaration of '__sanitizer::stat64'
  unsigned struct_stat64_sz = sizeof(struct stat64);
                                            ^
/Volumes/Android/srhines/aosp-llvm-r365631/toolchain/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.cc:195:33: error: invalid application of 'sizeof' to an incomplete type 'struct statfs64'
  unsigned struct_statfs64_sz = sizeof(struct statfs64);
                                ^     ~~~~~~~~~~~~~~~~~
/Volumes/Android/srhines/aosp-llvm-r365631/toolchain/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.cc:195:47: note: forward declaration of '__sanitizer::statfs64'
  unsigned struct_statfs64_sz = sizeof(struct statfs64);
                                              ^
2 errors generated.
ninja: build stopped: subcommand failed.
FAILED: cd /Volumes/Android/srhines/aosp-llvm-r365631/out/stage2/tools/clang/runtime/compiler-rt-bins && /Volumes/Android/srhines/aosp-llvm-r365631/prebuilts/cmake/darwin-x86/bin/cmake --build . && /Volumes/Android/srhines/aosp-llvm-r365631/prebuilts/cmake/darwin-x86/bin/cmake -E touch /Volumes/Android/srhines/aosp-llvm-r365631/out/stage2/tools/clang/runtime/compiler-rt-stamps//compiler-rt-build

To view this discussion on the web visit https://groups.google.com/d/msgid/android-llvm/CADCT%2BCN-q%3DEUX5RgNZ2A%2B08iP%2BJoDK0XkWJ4D8yAmTZTrYkA%2Bw%40mail.gmail.com.

[Pirama Arumuga Nainar]

Please ignore the link below to toolchain/llvm_android/base_builders.py - it's only for autoconf-based builds.  LLVM's CMake adds these automatically.

On Fri, Sep 3, 2021 at 1:04 PM Stephen Hines <srh...@google.com> wrote:

I tried a local build on my upgraded Mac, and also hit a build failure, so perhaps there is something more wrong here with the r365631 build on newer Macos versions. Pirama, are you suggesting that we're using the wrong `-isysroot`? There appear to be 2 instances of this, and just looking at my Mac install, there is only that 1 .sdk directory structure available (i.e. I don't have anything for older SDKs).

I'm saying (rather guessing) that the llvm-r365631 branch may be missing upstream LLVM changes to make it work with newer MacOS/SDK versions.

[Stephen Hines]

On Fri, Sep 3, 2021 at 1:08 PM Pirama Arumuga Nainar <pir...@google.com> wrote:

Please ignore the link below to toolchain/llvm_android/base_builders.py - it's only for autoconf-based builds.  LLVM's CMake adds these automatically.

On Fri, Sep 3, 2021 at 1:04 PM Stephen Hines <srh...@google.com> wrote:

I tried a local build on my upgraded Mac, and also hit a build failure, so perhaps there is something more wrong here with the r365631 build on newer Macos versions. Pirama, are you suggesting that we're using the wrong `-isysroot`? There appear to be 2 instances of this, and just looking at my Mac install, there is only that 1 .sdk directory structure available (i.e. I don't have anything for older SDKs).

I'm saying (rather guessing) that the llvm-r365631 branch may be missing upstream LLVM changes to make it work with newer MacOS/SDK versions.

True, I'll go peek at what's failing here for me. It's likely that Naville's errors will be similar (might just be seeing a different failure that breaks the build so far).

Thanks,

Steve

[Pirama Arumuga Nainar]

On Fri, Sep 3, 2021 at 1:10 PM Stephen Hines <srh...@google.com> wrote:

On Fri, Sep 3, 2021 at 1:08 PM Pirama Arumuga Nainar <pir...@google.com> wrote:

Please ignore the link below to toolchain/llvm_android/base_builders.py - it's only for autoconf-based builds.  LLVM's CMake adds these automatically.

On Fri, Sep 3, 2021 at 1:04 PM Stephen Hines <srh...@google.com> wrote:

I tried a local build on my upgraded Mac, and also hit a build failure, so perhaps there is something more wrong here with the r365631 build on newer Macos versions. Pirama, are you suggesting that we're using the wrong `-isysroot`? There appear to be 2 instances of this, and just looking at my Mac install, there is only that 1 .sdk directory structure available (i.e. I don't have anything for older SDKs).

I'm saying (rather guessing) that the llvm-r365631 branch may be missing upstream LLVM changes to make it work with newer MacOS/SDK versions.

True, I'll go peek at what's failing here for me. It's likely that Naville's errors will be similar (might just be seeing a different failure that breaks the build so far).

It is the same error, per CMakeError.log in  https://github.com/android/ndk/issues/1575.

[Stephen Hines]

So, something extremely fishy here that I think is probably causing us extra grief is that this is now building for universal support (`-arch arm64 -arch x86_64 -arch x86_64h` in the command line I mentioned below). We most certainly were not creating universal binaries or libraries for r365631, so I think the simplest solution might be disabling the arm64 aspect of these builds.

Steve

[Stephen Hines]

I found a variable named `DARWIN_osx_ARCHS` that is being set incorrectly now that we're all using newer MAC SDKs. https://cs.android.com/android-llvm/toolchain/llvm-project/+/llvm-r365631:compiler-rt/cmake/config-ix.cmake is the file where most of this takes place incorrectly (at least for newer MAC tools that have awareness of arm64, as well as x86_64h, which is a haswell+ variant of their normal x86 code generation.

https://reviews.llvm.org/rGef163f5a20dcd1f79f66ae2a71d425345e5453ac appears to be the missing patch, and I think it might be easiest for me to cherry-pick this into the r365631 branch so that you (and others) can continue to build as needed. https://reviews.llvm.org/rGb2303debfa63b60c21c93c318bed63341564a549 might also be needed, but I'm not 100% sure just yet. I have build going again now, and will see what works. If that still fails, I'll try adding the second patch, and see what happens. I think I'm pretty close to getting this working though, especially since it's now pretty obvious what has gone wrong (I did verify that the original failing compilation produces 3 .ii files, one of which for arm64 has the missing stat64 declaration).

Steve

[Stephen Hines]

Heh, it did need both patches. I just need the two patches from https://android-review.googlesource.com/c/toolchain/llvm-project/+/1818521 and https://android-review.googlesource.com/c/toolchain/llvm-project/+/1818520 approved, and we'll be all set here. Please feel free to try cherry-picking those to unblock yourself. In the future, you can just do `repo init -b llvm-r365631` and then `repo sync` that repository to have the latest sources for this particular release of our LLVM tools. Thanks for noticing/reporting the issue, and also for being patient with me while I worked out what was going wrong.

Thanks,

Steve

[Naville Zhang]

Thanks!

Our current pipeline uses the manifest approach to rebuild the entire ndk toolkit so I'm a bit lost from here.

Do I just switch to llvm-project's directory and re-run `repo init`?

Or, if I just manually invoke CMake by hand, what's the "appropiate" args?

Zhang

[Naville Zhang]

My pipeline now looks like this:

```

repo init -u https://android.googlesource.com/platform/manifest -b llvm-toolchain --depth=1

cp ${WORKSPACE}/Luminescent/.ci/manifest_7019983.xml .repo/manifests

repo init -m manifest_7019983.xml

repo sync -c -j 12

cd ${WORKSPACE}/llvm-toolchain/toolchain/llvm-project/

repo init -b llvm-r365631

repo sync -f

cd ${WORKSPACE}/llvm-toolchain/

python toolchain/llvm_android/build.py --enable-assertions

```

But I'm still seeing the same error:

```

INFO:__main__:check_call:15:17:06 /Users/naville/Development/NDK1/llvm-toolchain/prebuilts/cmake/darwin-x86/bin/cmake -G Ninja -DCMAKE_PREFIX_PATH=/Users/naville/Development/NDK1/llvm-toolchain/prebuilts/cmake/darwin-x86/bin -DLLVM_BUILD_EXTERNAL_COMPILER_RT=ON "-DCMAKE_SHARED_LINKER_FLAGS=-L/Users/naville/Development/NDK1/llvm-toolchain/prebuilts/clang/host/darwin-x86/clang-r365631b/lib64 -Wl,-rpath,/Users/naville/Development/NDK1/llvm-toolchain/prebuilts/clang/host/darwin-x86/clang-r365631b/lib64" -DLLVM_ENABLE_ASSERTIONS=OFF -DCMAKE_CXX_FLAGS=-fdebug-prefix-map=/Users/naville/Development/NDK1/llvm-toolchain= "-DCMAKE_MODULE_LINKER_FLAGS=-L/Users/naville/Development/NDK1/llvm-toolchain/prebuilts/clang/host/darwin-x86/clang-r365631b/lib64 -Wl,-rpath,/Users/naville/Development/NDK1/llvm-toolchain/prebuilts/clang/host/darwin-x86/clang-r365631b/lib64" -DCLANG_REPOSITORY_STRING=https://android.googlesource.com/toolchain/llvm-project -DLLVM_ENABLE_TERMINFO=OFF -DCLANG_VERSION_PATCHLEVEL=9 -DCOMPILER_RT_BUILD_XRAY=OFF -DLLVM_ENABLE_THREADS=ON -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_BUILD_TOOLS=OFF -DCMAKE_CXX_COMPILER=/Users/naville/Development/NDK1/llvm-toolchain/prebuilts/clang/host/darwin-x86/clang-r365631b/bin/clang++ -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_LIBCXX=ON -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY -DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY -DCMAKE_SYSROOT= -DLLVM_ENABLE_PROJECTS=clang;lld;libcxxabi;libcxx;compiler-rt -DCMAKE_FIND_ROOT_PATH_MODE_PROGRAM=NEVER -DCLANG_ENABLE_ARCMT=OFF -DLLVM_LIBDIR_SUFFIX=64 "-DCLANG_VENDOR=Android (dev based on r365631c3) " -DCMAKE_C_FLAGS=-fdebug-prefix-map=/Users/naville/Development/NDK1/llvm-toolchain= -DBUG_REPORT_URL=https://github.com/android-ndk/ndk/issues -DLLVM_BINUTILS_INCDIR=/Users/naville/Development/NDK1/llvm-toolchain/toolchain/binutils/binutils-2.27/include -DLLVM_USE_NEWPM=ON "-DCMAKE_EXE_LINKER_FLAGS=-L/Users/naville/Development/NDK1/llvm-toolchain/prebuilts/clang/host/darwin-x86/clang-r365631b/lib64 -Wl,-rpath,/Users/naville/Development/NDK1/llvm-toolchain/prebuilts/clang/host/darwin-x86/clang-r365631b/lib64" -DCOMPILER_RT_BUILD_LIBFUZZER=OFF -DLLVM_VERSION_PATCH=9 -DLLVM_BUILD_RUNTIME=ON -DCMAKE_INSTALL_PREFIX=/Users/naville/Development/NDK1/llvm-toolchain/out/stage1-install -DCLANG_ENABLE_STATIC_ANALYZER=OFF -DCMAKE_FIND_ROOT_PATH_MODE_PACKAGE=ONLY -DCMAKE_C_COMPILER=/Users/naville/Development/NDK1/llvm-toolchain/prebuilts/clang/host/darwin-x86/clang-r365631b/bin/clang -DCMAKE_OSX_DEPLOYMENT_TARGET=10.9 -DCMAKE_ASM_FLAGS=-fdebug-prefix-map=/Users/naville/Development/NDK1/llvm-toolchain= -DLLVM_TARGETS_TO_BUILD=X86 /Users/naville/Development/NDK1/llvm-toolchain/toolchain/llvm-project/llvm

-- The C compiler identification is Clang 9.0.7

-- The CXX compiler identification is Clang 9.0.7

-- The ASM compiler identification is Clang

-- Found assembler: /Users/naville/Development/NDK1/llvm-toolchain/prebuilts/clang/host/darwin-x86/clang-r365631b/bin/clang

-- Check for working C compiler: /Users/naville/Development/NDK1/llvm-toolchain/prebuilts/clang/host/darwin-x86/clang-r365631b/bin/clang

-- Check for working C compiler: /Users/naville/Development/NDK1/llvm-toolchain/prebuilts/clang/host/darwin-x86/clang-r365631b/bin/clang -- works

-- Detecting C compiler ABI info

-- Detecting C compiler ABI info - done

-- Detecting C compile features

-- Detecting C compile features - done

-- Check for working CXX compiler: /Users/naville/Development/NDK1/llvm-toolchain/prebuilts/clang/host/darwin-x86/clang-r365631b/bin/clang++

-- Check for working CXX compiler: /Users/naville/Development/NDK1/llvm-toolchain/prebuilts/clang/host/darwin-x86/clang-r365631b/bin/clang++ -- works

-- Detecting CXX compiler ABI info

-- Detecting CXX compiler ABI info - done

-- Detecting CXX compile features

-- Detecting CXX compile features - done

-- clang project is enabled

-- clang-tools-extra project is disabled

-- compiler-rt project is enabled

-- debuginfo-tests project is disabled

-- libclc project is disabled

-- libcxx project is enabled

-- libcxxabi project is enabled

-- libunwind project is disabled

-- lld project is enabled

-- lldb project is disabled

-- llgo project is disabled

-- openmp project is disabled

-- parallel-libs project is disabled

-- polly project is disabled

-- pstl project is disabled

-- Found Z3: /usr/local/lib/libz3.dylib (found suitable version "4.8.9", minimum required is "4.7.1") 

-- Found libtool - /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool

-- Performing Test CXX_COMPILER_SUPPORTS_STDLIB

-- Performing Test CXX_COMPILER_SUPPORTS_STDLIB - Success

-- Performing Test CXX_LINKER_SUPPORTS_STDLIB

-- Performing Test CXX_LINKER_SUPPORTS_STDLIB - Success

-- Looking for dlfcn.h

-- Looking for dlfcn.h - found

-- Looking for errno.h

-- Looking for errno.h - found

-- Looking for fcntl.h

-- Looking for fcntl.h - found

-- Looking for link.h

-- Looking for link.h - not found

-- Looking for malloc/malloc.h

-- Looking for malloc/malloc.h - found

-- Looking for pthread.h

-- Looking for pthread.h - found

-- Looking for signal.h

-- Looking for signal.h - found

-- Looking for sys/ioctl.h

-- Looking for sys/ioctl.h - found

-- Looking for sys/mman.h

-- Looking for sys/mman.h - found

-- Looking for sys/param.h

-- Looking for sys/param.h - found

-- Looking for sys/resource.h

-- Looking for sys/resource.h - found

-- Looking for sys/stat.h

-- Looking for sys/stat.h - found

-- Looking for sys/time.h

-- Looking for sys/time.h - found

-- Looking for sys/types.h

-- Looking for sys/types.h - found

-- Looking for termios.h

-- Looking for termios.h - found

-- Looking for unistd.h

-- Looking for unistd.h - found

-- Looking for valgrind/valgrind.h

-- Looking for valgrind/valgrind.h - not found

-- Looking for zlib.h

-- Looking for zlib.h - found

-- Looking for fenv.h

-- Looking for fenv.h - found

-- Looking for FE_ALL_EXCEPT

-- Looking for FE_ALL_EXCEPT - found

-- Looking for FE_INEXACT

-- Looking for FE_INEXACT - found

-- Looking for mach/mach.h

-- Looking for mach/mach.h - found

-- Looking for histedit.h

-- Looking for histedit.h - found

-- Looking for CrashReporterClient.h

-- Looking for CrashReporterClient.h - not found

-- Performing Test HAVE_CRASHREPORTER_INFO

-- Performing Test HAVE_CRASHREPORTER_INFO - Success

-- Looking for pthread_create in pthread

-- Looking for pthread_create in pthread - found

-- Looking for pthread_getspecific in pthread

-- Looking for pthread_getspecific in pthread - found

-- Looking for pthread_rwlock_init in pthread

-- Looking for pthread_rwlock_init in pthread - found

-- Looking for pthread_mutex_lock in pthread

-- Looking for pthread_mutex_lock in pthread - found

-- Looking for dlopen in dl

-- Looking for dlopen in dl - found

-- Looking for clock_gettime in rt

-- Looking for clock_gettime in rt - not found

-- Looking for pfm_initialize in pfm

-- Looking for pfm_initialize in pfm - not found

-- Looking for pthread.h

-- Looking for pthread.h - found

-- Looking for pthread_create

-- Looking for pthread_create - found

-- Found Threads: TRUE  

-- Looking for compress2 in z

-- Looking for compress2 in z - found

-- Looking for el_init in edit

-- Looking for el_init in edit - found

-- Found LibXml2: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/lib/libxml2.tbd (found version "2.9.4") 

-- Looking for xar_open in xar

-- Looking for xar_open in xar - found

-- Looking for arc4random

-- Looking for arc4random - found

-- Looking for backtrace

-- Looking for backtrace - found

-- backtrace facility detected in default set of libraries

-- Found Backtrace: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include  

-- Performing Test C_SUPPORTS_WERROR_UNGUARDED_AVAILABILITY_NEW

-- Performing Test C_SUPPORTS_WERROR_UNGUARDED_AVAILABILITY_NEW - Success

-- Looking for _Unwind_Backtrace

-- Looking for _Unwind_Backtrace - found

-- Looking for getpagesize

-- Looking for getpagesize - found

-- Looking for sysconf

-- Looking for sysconf - found

-- Looking for getrusage

-- Looking for getrusage - found

-- Looking for setrlimit

-- Looking for setrlimit - found

-- Looking for isatty

-- Looking for isatty - found

-- Looking for futimens

-- Looking for futimens - not found

-- Looking for futimes

-- Looking for futimes - found

-- Looking for posix_fallocate

-- Looking for posix_fallocate - not found

-- Looking for lseek64

-- Looking for lseek64 - not found

-- Looking for mallctl

-- Looking for mallctl - not found

-- Looking for mallinfo

-- Looking for mallinfo - not found

-- Looking for malloc_zone_statistics

-- Looking for malloc_zone_statistics - found

-- Looking for getrlimit

-- Looking for getrlimit - found

-- Looking for posix_spawn

-- Looking for posix_spawn - found

-- Looking for pread

-- Looking for pread - found

-- Looking for sbrk

-- Looking for sbrk - found

-- Looking for strerror

-- Looking for strerror - found

-- Looking for strerror_r

-- Looking for strerror_r - found

-- Looking for strerror_s

-- Looking for strerror_s - not found

-- Looking for setenv

-- Looking for setenv - found

-- Looking for dlopen

-- Looking for dlopen - found

-- Looking for dladdr

-- Looking for dladdr - found

-- Performing Test HAVE_STRUCT_STAT_ST_MTIMESPEC_TV_NSEC

-- Performing Test HAVE_STRUCT_STAT_ST_MTIMESPEC_TV_NSEC - Success

-- Performing Test HAVE_STRUCT_STAT_ST_MTIM_TV_NSEC

-- Performing Test HAVE_STRUCT_STAT_ST_MTIM_TV_NSEC - Failed

-- Looking for __GLIBC__

-- Looking for __GLIBC__ - not found

-- Looking for sched_getaffinity

-- Looking for sched_getaffinity - not found

-- Looking for CPU_COUNT

-- Looking for CPU_COUNT - not found

-- Looking for pthread_getname_np

-- Looking for pthread_getname_np - found

-- Looking for pthread_setname_np

-- Looking for pthread_setname_np - found

-- Performing Test HAVE_STD_IS_TRIVIALLY_COPYABLE

-- Performing Test HAVE_STD_IS_TRIVIALLY_COPYABLE - Success

-- Performing Test HAVE_CXX_ATOMICS_WITHOUT_LIB

-- Performing Test HAVE_CXX_ATOMICS_WITHOUT_LIB - Failed

-- Looking for __atomic_fetch_add_4 in atomic

-- Looking for __atomic_fetch_add_4 in atomic - not found

CMake Error at cmake/modules/CheckAtomic.cmake:53 (message):

  Host compiler appears to require libatomic, but cannot find it.

Call Stack (most recent call first):

  cmake/config-ix.cmake:343 (include)

  CMakeLists.txt:617 (include)

```

[Naville Zhang]

Can confirm toolchain/llvm-project has commit SHA1: 6fcb292a031f43eab23dcd57abcd449228ecad36, 

CMakeError.log contains the same error about linking failure with missing -latomic, I suspect the one I'm encountering is not the same as the one you've fixed

在2021年9月4日星期六 UTC+8 下午1:02:12<Stephen Hines> 写道：

[Naville Zhang]

It seems that on macOS, libatomic is not required and the test only failed because it failed to find ``std::int32_t and alike``, which results the initial test failure.

Minimal test case:

```

#include <atomic>

std::atomic<int> x;

int main() {

  return x;

}

```

Invoking System Clang, which successfully builds the test program:

```

clang++  -stdlib=libc++ -std=c++11 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk test.cpp -v

```

gives us the following header search path:

```

ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/local/include"

ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/Library/Frameworks"

#include "..." search starts here:

#include <...> search starts here:

 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/c++/v1

 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/12.0.5/include

 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include

 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include

 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/System/Library/Frameworks (framework directory)

End of search list.

```

and if the same commands is used to invoke NDK's prebuilt clang:

```

#include "..." search starts here:

#include <...> search starts here:

 /Users/naville/Development/NDK1/llvm-toolchain/prebuilts/clang/host/darwin-x86/clang-r365631b/bin/../include/c++/v1

 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/c++/v1

 /Users/naville/Development/NDK1/llvm-toolchain/prebuilts/clang/host/darwin-x86/clang-r365631b/lib64/clang/9.0.7/include

 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include

 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/System/Library/Frameworks (framework directory)

End of search list.

In file included from test.cpp:1:

In file included from /Users/naville/Development/NDK1/llvm-toolchain/prebuilts/clang/host/darwin-x86/clang-r365631b/bin/../include/c++/v1/atomic:551:

/Users/naville/Development/NDK1/llvm-toolchain/prebuilts/clang/host/darwin-x86/clang-r365631b/bin/../include/c++/v1/cstdint:152:8: error: no member named 'int8_t' in the

      global namespace

using::int8_t;

     ~~^

/Users/naville/Development/NDK1/llvm-toolchain/prebuilts/clang/host/darwin-x86/clang-r365631b/bin/../include/c++/v1/cstdint:153:8: error: no member named 'int16_t' in

      the global namespace

using::int16_t;

     ~~^

/Users/naville/Development/NDK1/llvm-toolchain/prebuilts/clang/host/darwin-x86/clang-r365631b/bin/../include/c++/v1/cstdint:154:8: error: no member named 'int32_t' in

      the global namespace

using::int32_t;

     ~~^

```

Notice the header search path ordering

[Naville Zhang]

So, a **VERY** dirty move would be deleting ``prebuilts/clang/host/darwin-x86/clang-r365631b/bin/../include/``, which forces Clang to fallback to the C++ STL shipped with Xcode.

This fixed the aforementioned trivial sample for me with NDK prebuilt clang, not sure if this is correct (probably not) but it at least gets me pass the initial configuration stage

Zhang

[Naville Zhang]

Nope, likely due to we deleted NDK C++ STL but still misses the STL at ``/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include``

I figured the best approach here would still be using full stock Clang

[Naville Zhang]

Ping. Is this fixable or am I forced to use  10.13?

[Stephen Hines]

Hi Naville,

Sorry for the delay. I unfortunately can't run an older MacOS for building this any more (corp policies basically force us onto the latest versions, and I don't have any reasonable access to an older Mac). We do all our builds on 10.13 or higher (11.5 these days actually), so that might be a better option too. It still can produce a toolchain that works on older MacOS, but XCode remains very complex to interact with (especially when building newer software).

Can you try removing the `--enable-assertions` flag from your build? We don't build with that flag on in automation or production, and that might be why we're not seeing this failure. I don't suggest removing the STL directories as your previous email suggested, as then you are depending on more of the host machine's environment, which might make those tools unable to run on older MacOS versions.

Steve

To view this discussion on the web visit https://groups.google.com/d/msgid/android-llvm/c9061d68-d388-4e6b-a8fe-dabec3c11a2en%40googlegroups.com.

[Naville Zhang]

Hi:

I highly doubt this is the case, since from CMakeError.log it seems the error roots from:

- CMake tried to detect if the compiler needs libatomic, but failed because the test program can't find std::uint32_t and alike when using NDK's prebuilt STL.

- CMake thought itself needs libatomic due to the aforementioned failure.

Which is why I tried to remove NDK's STL and fallback to stock Apple Clang STL, which yields other issues, suggesting something I'm attempting isn't 100% correct