[CMake] Disable 64bit file position on old 32 bit Androids

[eugene]

Summary

This is needed for building LLVM on Android with new NDK (newer than r15c) and API level < 24. Android C library (Bionic) didn't have support for 64 bit file position until Android N.

[krytarowski]

I would add in the commit description that this is Linux/Android specific. For the reference, 32bit systems like BSD ship with 64bit off_t always.

[pirama]

https://reviews.llvm.org/D35648 does something similar. If this is just for building compiler-rt runtimes, we can defer to that patch. This way we can just remove the exception for Android once the NDK defaults to something past API level 24, rather than support a build configuration for ever.

[eugene]

Added comment

[eugene]

In D37314#857186, @pirama wrote:

https://reviews.llvm.org/D35648 does something similar. If this is just for building compiler-rt runtimes, we can defer to that patch. This way we can just remove the exception for Android once the NDK defaults to something past API level 24, rather than support a build configuration for ever.

I need this for LLDB support on Android. It's going to be a long while till LLDB can default to API level 24.

[pirama]

In D37314#857200, @eugene wrote:

In D37314#857186, @pirama wrote:

https://reviews.llvm.org/D35648 does something similar. If this is just for building compiler-rt runtimes, we can defer to that patch. This way we can just remove the exception for Android once the NDK defaults to something past API level 24, rather than support a build configuration for ever.

I need this for LLDB support on Android. It's going to be a long while till LLDB can default to API level 24.

Aah, ok. So https://reviews.llvm.org/D35648 doesn't cover your use case. Can we just say "AND (NOT ANDROID)" instead of a new CMake option?

[eugene]

Aah, ok. So https://reviews.llvm.org/D35648 doesn't cover your use case. Can we just say "AND (NOT ANDROID)" instead of a new CMake option?

Sure we can. I just wanted it to be a bit more flexible.

[aoli]

Pirama: shall I remove remove_definitions(-D_FILE_OFFSET_BITS=64) in https://reviews.llvm.org/D35648? Or we don't want FILE_OFFSET_BITS=64 for runtimes no matter what ANDROID_NATIVE_API_LEVEL is.

[pirama]

LGTM for Android, but I'll let other reviewers formally accept it, in case they have build-system centric comments.

In D37314#857392, @aoli wrote:

Pirama: shall I remove remove_definitions(-D_FILE_OFFSET_BITS=64) in https://reviews.llvm.org/D35648? Or we don't want FILE_OFFSET_BITS=64 for runtimes no matter what ANDROID_NATIVE_API_LEVEL is.

We should remove the line you mention above once this change goes in.

[eugene]

Could somebody please take another look at this change? It would help us fix an internal build with the latest NDK.

llvm/trunk/cmake/modules/HandleLLVMOptions.cmake

if( LLVM_BUILD_32_BITS )
     set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -m32")
     set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -m32")
     set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -m32")
     set(CMAKE_MODULE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS} -m32")
   endif( LLVM_BUILD_32_BITS )
 endif( CMAKE_SIZEOF_VOID_P EQUAL 8 AND NOT WIN32 )
 
 # If building on a GNU specific 32-bit system, make sure off_t is 64 bits
-# so that off_t can stored offset > 2GB
-if( CMAKE_SIZEOF_VOID_P EQUAL 4 )
+# so that off_t can stored offset > 2GB.
+# Android until version N (API 24) doesn't support it.
+if (ANDROID AND (ANDROID_NATIVE_API_LEVEL LESS 24))
+  set(LLVM_FORCE_SMALLFILE_FOR_ANDROID TRUE)
+endif()
+if( CMAKE_SIZEOF_VOID_P EQUAL 4 AND NOT LLVM_FORCE_SMALLFILE_FOR_ANDROID)
   add_definitions( -D_LARGEFILE_SOURCE )
   add_definitions( -D_FILE_OFFSET_BITS=64 )
 endif()
 
 if( XCODE )
   # For Xcode enable several build settings that correspond to
   # many warnings that are on by default in Clang but are
   # not enabled for historical reasons.  For versions of Xcode

 endif()
 
 if( MSVC )
   if( CMAKE_CXX_COMPILER_VERSION VERSION_LESS 19.0 )
     # For MSVC 2013, disable iterator null pointer checking in debug mode,
     # especially so std::equal(nullptr, nullptr, nullptr) will not assert.
     add_definitions("-D_DEBUG_POINTER_IMPL=")
   endif()
-  
   include(ChooseMSVCCRT)
 
   if( MSVC11 )
     add_definitions(-D_VARIADIC_MAX=10)
   endif()
-  
   # Add definitions that make MSVC much less annoying.
   add_definitions(
     # For some reason MS wants to deprecate a bunch of standard functions...
     -D_CRT_SECURE_NO_DEPRECATE
     -D_CRT_SECURE_NO_WARNINGS
     -D_CRT_NONSTDC_NO_DEPRECATE
     -D_CRT_NONSTDC_NO_WARNINGS
     -D_SCL_SECURE_NO_DEPRECATE
if (SUPPORTS_BREPRO)
       # Check if /INCREMENTAL is passed to the linker and complain that it
       # won't work with /Brepro.
       string(TOUPPER "${CMAKE_EXE_LINKER_FLAGS}" upper_exe_flags)
       string(TOUPPER "${CMAKE_MODULE_LINKER_FLAGS}" upper_module_flags)
       string(TOUPPER "${CMAKE_SHARED_LINKER_FLAGS}" upper_shared_flags)
 
       string(FIND "${upper_exe_flags} ${upper_module_flags} ${upper_shared_flags}"
         "/INCREMENTAL" linker_flag_idx)
-      
       if (${linker_flag_idx} GREATER -1)
         message(WARNING "/Brepro not compatible with /INCREMENTAL linking - builds will be non-deterministic")
       else()
         append("/Brepro" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
       endif()
     endif()
   endif()