Re: Building on android....

[Gregory Casamento]

I confess I didn’t see them.

On Fri, Feb 15, 2019 at 16:59 Ivan Vučica  wrote:

> Did you try to analyze what my projects which I shared with you are doing
> to produce an APK?
>
> On Fri 15 Feb 2019 at 21:57, Gregory Casamento 
> wrote:
>
>> Any possibility that you might be willing to share the cmake files and
>> config options you used?   One direction I would like to take the project
>> in is to Be able to compile on android and potentially have a uikit
>> implementation on top of android.
>>
>> On Fri, Feb 15, 2019 at 15:24 Jordan Schidlowsky 
>> wrote:
>>
>>> Sorry, ya I'm just seeing that script now, we didn't use that.  Just
>>> looked at configuration options for tools-make and gnustep-base...  Then
>>> fixed everything that didn't configure properly for cross-compilation and
>>> re-wrote a CMakelists.txt for base and have been using that since...
>>> Having the whole build (from runtime to base) in cmake makes it much easie
>>> to write, run, and debug everything inside android studio (even though the
>>> IDE editor doesn't support obj-c syntax).
>>>
>>>
>>> On Feb 15, 2019, at 2:02 PM, Gregory Casamento 
>>> wrote:
>>>
>>> The one we were discussing in this thread.  How are you configuring your
>>> app on android?
>>>
>>> On Fri, Feb 15, 2019 at 14:55 Jordan Schidlowsky 
>>> wrote:
>>>
 Sorry, i'm not sure which script you're referring to!

 On Feb 15, 2019, at 1:44 PM, Gregory Casamento <
 greg.casame...@gmail.com> wrote:

 Are you talking about how the script configures things?

 On Fri, Feb 15, 2019 at 12:08 Jordan Schidlowsky 
 wrote:

> We will be shipping a large game in a couple weeks on android that is
> built on gnustep.   We've been testing very extensively over the past 3-4
> months and things look quite stable (at least on armv7-a).  The game
> heavily uses ARC, blocks, libdispatch  Lemme just say the 
> configuration
> of gnustep-base, build, and project setup, were not ideal.
>
> On Feb 15, 2019, at 11:04 AM, Gregory Casamento <
> greg.casame...@gmail.com> wrote:
>
> The challenge at this point is to get a working app.
>
> On Wed, Feb 13, 2019 at 14:47 Gregory Casamento <
> greg.casame...@gmail.com> wrote:
>
>> Ivan pointed out that I was using the wrong ninja script.  This
>> solved my problem.   I am now working on getting base to build properly.
>>
>> GC
>>
>> On Wed, Feb 13, 2019 at 12:21 PM Ivan Vučica  wrote:
>>
>>> FTR thank you for that, and for spotting -androideabi16!
>>>
>>> On Wed, Feb 13, 2019 at 5:20 PM Jordan Schidlowsky <
>>> jor...@noodlecake.com> wrote:
>>>
 Agreed, just sharing whats working for us via gradle config.

 On Feb 13, 2019, at 11:17 AM, Ivan Vučica  wrote:

 Aye; but we should not depend on using Gradle as the end state.

 On Wed, Feb 13, 2019 at 5:09 PM Jordan Schidlowsky <
 jor...@noodlecake.com> wrote:

> Ya you're right,  It should be picked up.  For what it's worth,
> here's our gradle config, (which ends up passing the correct flags to 
> cmake
> for building gnustep):
>
> defaultConfig {
> applicationId "com.noodlecake.ssg4"
> minSdkVersion 21
> targetSdkVersion 28
> versionCode 28
> versionName "1.0.0"
> testInstrumentationRunner 
> "android.support.test.runner.AndroidJUnitRunner"
> externalNativeBuild {
> cmake {
> cppFlags "-std=c++14 -frtti -fexceptions 
> -fconstant-string-class=NSConstantString"
> cFlags "-DANDROID 
> -fconstant-string-class=NSConstantString"
> arguments "-DCMAKE_VERBOSE_MAKEFILE=ON",
> "-DANDROID_STL=c++_static",
> "-DANDROID_DISABLE_FORMAT_STRING_CHECKS=TRUE"
> }
> }
> ndk {
> // Specifies the ABI configurations of your native
> // libraries Gradle should build and package with your APK.
> //abiFilters 'x86', 'x86_64', 'armeabi', 'armeabi-v7a',
> //'arm64-v8a'
> abiFilters 'armeabi-v7a'
> }
> }
>
>
>
>
> On Feb 13, 2019, at 11:03 AM, Ivan Vučica  wrote:
>
> Reading through the toolchain file
> ,
> ANDROID_PLATFORM will be calculated from ANDROID_NATIVE_API_LEVEL. So 
> that
> should not be the issue.
>
> I'd start by pepper-spraying 

Re: Building on android....

[Jordan Schidlowsky]

I'll share here but there's so custom hacks going on that it may not be really 
that useful yet... You'll also need to modify the NDK's cmake toolchain to 
recognize .m and .mm as source files as well.We have a bare bones uikit 
running based roughly on the chameleon project, but really just use UITouch and 
UIView to setup one view that we can render an EAGLContext in...  There are a 
couple of projects that we pull in as well: libdispatch, libffi, pixman, 
cairo...

The custom android classes are implementations of some of the platform specific 
stuff that makes no sense on android... (NSBundle, etc).  In an ideal world it 
would be nice if there was some version of foundation that was just a language 
standard library instead of bundling all the platform stuff in as well. Oh well 
 ¯\_(ツ)_/¯

Anyways, Android-Studio base CMakelists.txt looks like this:
--
--
--
cmake_minimum_required(VERSION 3.4.1)

find_library(log-lib log)
find_library(z-lib z)
find_library(gles-lib GLESv2)
find_library(opensl-lib OpenSLES)

# build cpufeatures as a static lib
add_library(cpufeatures STATIC
${ANDROID_NDK}/sources/android/cpufeatures/cpu-features.c)

set(ANDROID TRUE)

# Sub-projects
add_subdirectory( libs/libobjc2 )
add_subdirectory( libs/dispatch )
add_subdirectory( libs/libffi )
add_subdirectory( libs/libs-base )

--
--
--
And then libs-base CMakeLists.txt:
--
--
--

cmake_minimum_required(VERSION 3.4.1)
INCLUDE (CheckIncludeFiles)

project(foundation)

set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fblocks -D__BLOCKS__ 
-fobjc-runtime=gnustep-1.9 \
-Wno-implicit-function-declaration \
-DGNUSTEP -DNS_BLOCKS_AVAILABLE -DGNUSTEP_BASE_LIBRARY=1 -DGNU_RUNTIME=1 
-DGNUSTEP_BASE_LIBRARY=1 \
-DGSWARN -DGSDIAGNOSE \
")


file(GLOB SRC
  Source/Additions/GSTypeEncoding.c
  Source/Additions/GSObjCRuntime.m
  Source/Additions/GCObject.m
  Source/Additions/GCArray.m
  Source/Additions/GCDictionary.m
  Source/Additions/GSLock.m
  Source/Additions/GSMime.m
  Source/Additions/GSXML.m
  Source/Additions/GSFunctions.m
  Source/Additions/GSInsensitiveDictionary.m
  Source/Additions/NSArray+GNUstepBase.m
  Source/Additions/NSAttributedString+GNUstepBase.m
  Source/Additions/NSBundle+GNUstepBase.m
  Source/Additions/NSCalendarDate+GNUstepBase.m
  Source/Additions/NSData+GNUstepBase.m
  Source/Additions/NSDebug+GNUstepBase.m
  Source/Additions/NSError+GNUstepBase.m
  Source/Additions/NSHashTable+GNUstepBase.m
  Source/Additions/NSFileHandle+GNUstepBase.m
  Source/Additions/NSLock+GNUstepBase.m
  Source/Additions/NSMutableString+GNUstepBase.m
  Source/Additions/NSNumber+GNUstepBase.m
  Source/Additions/NSObject+GNUstepBase.m
  Source/Additions/NSPropertyList+GNUstepBase.m
  Source/Additions/NSProcessInfo+GNUstepBase.m
  Source/Additions/NSStream+GNUstepBase.m
  Source/Additions/NSString+GNUstepBase.m
  Source/Additions/NSTask+GNUstepBase.m
  Source/Additions/NSThread+GNUstepBase.m
  Source/Additions/NSURL+GNUstepBase.m
  Source/Additions/Unicode.m

  # ? blocks???
  Source/unix/GSRunLoopCtxt.m
  Source/unix/NSStream.m

  Source/GSLocale.m
  Source/preface.m
  Source/cifframe.m
  Source/CXXException.m
  Source/GSArray.m
  Source/GSAttributedString.m
  Source/GSBlocks.m
  Source/GSConcreteValue.m
  Source/GSCountedSet.m
  Source/GSDictionary.m
  Source/GSFTPURLHandle.m
  Source/GSFormat.m
  Source/GSHTTPAuthentication.m
  Source/GSHTTPURLHandle.m
  Source/GSICUString.m
  Source/GSPrivateHash.m
  Source/GSQuickSort.m
  Source/GSRunLoopWatcher.m
  Source/GSSet.m
  Source/GSShellSort.m
  Source/GSSocketStream.m
  Source/GSSet.m
  Source/GSShellSort.m
  Source/GSSocketStream.m
  Source/GSStream.m
  Source/GSString.m
  Source/GSTimSort.m
  Source/GSTLS.m
  Source/GSValue.m
  Source/GSSocksParser.m
  Source/GSSocksParserPrivate.m
  Source/GSSocks4Parser.m
  Source/GSSocks5Parser.m
  Source/NSAffineTransform.m
  Source/NSArchiver.m
  Source/NSArray.m
  Source/NSAssertionHandler.m
  Source/NSAttributedString.m
  Source/NSAutoreleasePool.m
  #Source/NSBundle.m
  Source/NSCache.m
  Source/NSCachedURLResponse.m
  Source/NSCalendar.m
  Source/NSCalendarDate.m
  Source/NSCallBacks.m
  Source/NSCharacterSet.m
  Source/NSClassDescription.m
  Source/NSCoder.m
  Source

Re: Building on android....

[Ivan Vučica]

Did you try to analyze what my projects which I shared with you are doing
to produce an APK?

On Fri 15 Feb 2019 at 21:57, Gregory Casamento 
wrote:

> Any possibility that you might be willing to share the cmake files and
> config options you used?   One direction I would like to take the project
> in is to Be able to compile on android and potentially have a uikit
> implementation on top of android.
>
> On Fri, Feb 15, 2019 at 15:24 Jordan Schidlowsky 
> wrote:
>
>> Sorry, ya I'm just seeing that script now, we didn't use that.  Just
>> looked at configuration options for tools-make and gnustep-base...  Then
>> fixed everything that didn't configure properly for cross-compilation and
>> re-wrote a CMakelists.txt for base and have been using that since...
>> Having the whole build (from runtime to base) in cmake makes it much easie
>> to write, run, and debug everything inside android studio (even though the
>> IDE editor doesn't support obj-c syntax).
>>
>>
>> On Feb 15, 2019, at 2:02 PM, Gregory Casamento 
>> wrote:
>>
>> The one we were discussing in this thread.  How are you configuring your
>> app on android?
>>
>> On Fri, Feb 15, 2019 at 14:55 Jordan Schidlowsky 
>> wrote:
>>
>>> Sorry, i'm not sure which script you're referring to!
>>>
>>> On Feb 15, 2019, at 1:44 PM, Gregory Casamento 
>>> wrote:
>>>
>>> Are you talking about how the script configures things?
>>>
>>> On Fri, Feb 15, 2019 at 12:08 Jordan Schidlowsky 
>>> wrote:
>>>
 We will be shipping a large game in a couple weeks on android that is
 built on gnustep.   We've been testing very extensively over the past 3-4
 months and things look quite stable (at least on armv7-a).  The game
 heavily uses ARC, blocks, libdispatch  Lemme just say the configuration
 of gnustep-base, build, and project setup, were not ideal.

 On Feb 15, 2019, at 11:04 AM, Gregory Casamento <
 greg.casame...@gmail.com> wrote:

 The challenge at this point is to get a working app.

 On Wed, Feb 13, 2019 at 14:47 Gregory Casamento <
 greg.casame...@gmail.com> wrote:

> Ivan pointed out that I was using the wrong ninja script.  This solved
> my problem.   I am now working on getting base to build properly.
>
> GC
>
> On Wed, Feb 13, 2019 at 12:21 PM Ivan Vučica  wrote:
>
>> FTR thank you for that, and for spotting -androideabi16!
>>
>> On Wed, Feb 13, 2019 at 5:20 PM Jordan Schidlowsky <
>> jor...@noodlecake.com> wrote:
>>
>>> Agreed, just sharing whats working for us via gradle config.
>>>
>>> On Feb 13, 2019, at 11:17 AM, Ivan Vučica  wrote:
>>>
>>> Aye; but we should not depend on using Gradle as the end state.
>>>
>>> On Wed, Feb 13, 2019 at 5:09 PM Jordan Schidlowsky <
>>> jor...@noodlecake.com> wrote:
>>>
 Ya you're right,  It should be picked up.  For what it's worth,
 here's our gradle config, (which ends up passing the correct flags to 
 cmake
 for building gnustep):

 defaultConfig {
 applicationId "com.noodlecake.ssg4"
 minSdkVersion 21
 targetSdkVersion 28
 versionCode 28
 versionName "1.0.0"
 testInstrumentationRunner 
 "android.support.test.runner.AndroidJUnitRunner"
 externalNativeBuild {
 cmake {
 cppFlags "-std=c++14 -frtti -fexceptions 
 -fconstant-string-class=NSConstantString"
 cFlags "-DANDROID -fconstant-string-class=NSConstantString"
 arguments "-DCMAKE_VERBOSE_MAKEFILE=ON",
 "-DANDROID_STL=c++_static",
 "-DANDROID_DISABLE_FORMAT_STRING_CHECKS=TRUE"
 }
 }
 ndk {
 // Specifies the ABI configurations of your native
 // libraries Gradle should build and package with your APK.
 //abiFilters 'x86', 'x86_64', 'armeabi', 'armeabi-v7a',
 //'arm64-v8a'
 abiFilters 'armeabi-v7a'
 }
 }




 On Feb 13, 2019, at 11:03 AM, Ivan Vučica  wrote:

 Reading through the toolchain file
 ,
 ANDROID_PLATFORM will be calculated from ANDROID_NATIVE_API_LEVEL. So 
 that
 should not be the issue.

 I'd start by pepper-spraying message() calls in toolchain .cmake
 file, and in other .cmake files as necessary, too.

 On Wed, Feb 13, 2019 at 5:01 PM Jordan Schidlowsky <
 jor...@noodlecake.com> wrote:

> Ah, i didn't see that shel

Re: Building on android....

[Gregory Casamento]

Any possibility that you might be willing to share the cmake files and
config options you used?   One direction I would like to take the project
in is to Be able to compile on android and potentially have a uikit
implementation on top of android.

On Fri, Feb 15, 2019 at 15:24 Jordan Schidlowsky 
wrote:

> Sorry, ya I'm just seeing that script now, we didn't use that.  Just
> looked at configuration options for tools-make and gnustep-base...  Then
> fixed everything that didn't configure properly for cross-compilation and
> re-wrote a CMakelists.txt for base and have been using that since...
> Having the whole build (from runtime to base) in cmake makes it much easie
> to write, run, and debug everything inside android studio (even though the
> IDE editor doesn't support obj-c syntax).
>
>
> On Feb 15, 2019, at 2:02 PM, Gregory Casamento 
> wrote:
>
> The one we were discussing in this thread.  How are you configuring your
> app on android?
>
> On Fri, Feb 15, 2019 at 14:55 Jordan Schidlowsky 
> wrote:
>
>> Sorry, i'm not sure which script you're referring to!
>>
>> On Feb 15, 2019, at 1:44 PM, Gregory Casamento 
>> wrote:
>>
>> Are you talking about how the script configures things?
>>
>> On Fri, Feb 15, 2019 at 12:08 Jordan Schidlowsky 
>> wrote:
>>
>>> We will be shipping a large game in a couple weeks on android that is
>>> built on gnustep.   We've been testing very extensively over the past 3-4
>>> months and things look quite stable (at least on armv7-a).  The game
>>> heavily uses ARC, blocks, libdispatch  Lemme just say the configuration
>>> of gnustep-base, build, and project setup, were not ideal.
>>>
>>> On Feb 15, 2019, at 11:04 AM, Gregory Casamento <
>>> greg.casame...@gmail.com> wrote:
>>>
>>> The challenge at this point is to get a working app.
>>>
>>> On Wed, Feb 13, 2019 at 14:47 Gregory Casamento <
>>> greg.casame...@gmail.com> wrote:
>>>
 Ivan pointed out that I was using the wrong ninja script.  This solved
 my problem.   I am now working on getting base to build properly.

 GC

 On Wed, Feb 13, 2019 at 12:21 PM Ivan Vučica  wrote:

> FTR thank you for that, and for spotting -androideabi16!
>
> On Wed, Feb 13, 2019 at 5:20 PM Jordan Schidlowsky <
> jor...@noodlecake.com> wrote:
>
>> Agreed, just sharing whats working for us via gradle config.
>>
>> On Feb 13, 2019, at 11:17 AM, Ivan Vučica  wrote:
>>
>> Aye; but we should not depend on using Gradle as the end state.
>>
>> On Wed, Feb 13, 2019 at 5:09 PM Jordan Schidlowsky <
>> jor...@noodlecake.com> wrote:
>>
>>> Ya you're right,  It should be picked up.  For what it's worth,
>>> here's our gradle config, (which ends up passing the correct flags to 
>>> cmake
>>> for building gnustep):
>>>
>>> defaultConfig {
>>> applicationId "com.noodlecake.ssg4"
>>> minSdkVersion 21
>>> targetSdkVersion 28
>>> versionCode 28
>>> versionName "1.0.0"
>>> testInstrumentationRunner 
>>> "android.support.test.runner.AndroidJUnitRunner"
>>> externalNativeBuild {
>>> cmake {
>>> cppFlags "-std=c++14 -frtti -fexceptions 
>>> -fconstant-string-class=NSConstantString"
>>> cFlags "-DANDROID -fconstant-string-class=NSConstantString"
>>> arguments "-DCMAKE_VERBOSE_MAKEFILE=ON",
>>> "-DANDROID_STL=c++_static",
>>> "-DANDROID_DISABLE_FORMAT_STRING_CHECKS=TRUE"
>>> }
>>> }
>>> ndk {
>>> // Specifies the ABI configurations of your native
>>> // libraries Gradle should build and package with your APK.
>>> //abiFilters 'x86', 'x86_64', 'armeabi', 'armeabi-v7a',
>>> //'arm64-v8a'
>>> abiFilters 'armeabi-v7a'
>>> }
>>> }
>>>
>>>
>>>
>>>
>>> On Feb 13, 2019, at 11:03 AM, Ivan Vučica  wrote:
>>>
>>> Reading through the toolchain file
>>> ,
>>> ANDROID_PLATFORM will be calculated from ANDROID_NATIVE_API_LEVEL. So 
>>> that
>>> should not be the issue.
>>>
>>> I'd start by pepper-spraying message() calls in toolchain .cmake
>>> file, and in other .cmake files as necessary, too.
>>>
>>> On Wed, Feb 13, 2019 at 5:01 PM Jordan Schidlowsky <
>>> jor...@noodlecake.com> wrote:
>>>
 Ah, i didn't see that shell script...  I think
 -DANDROID_PLATFORM=android-21 (or 23) is what you want there.


 On Feb 13, 2019, at 10:53 AM, Ivan Vučica  wrote:

 Actually -- it doesn't explain why this is happening, as the shell
 script (which 

Re: Building on android....

[Jordan Schidlowsky]

Sorry, ya I'm just seeing that script now, we didn't use that.  Just looked at 
configuration options for tools-make and gnustep-base...  Then fixed everything 
that didn't configure properly for cross-compilation and re-wrote a 
CMakelists.txt for base and have been using that since...  Having the whole 
build (from runtime to base) in cmake makes it much easie to write, run, and 
debug everything inside android studio (even though the IDE editor doesn't 
support obj-c syntax).  

> On Feb 15, 2019, at 2:02 PM, Gregory Casamento  
> wrote:
> 
> The one we were discussing in this thread.  How are you configuring your app 
> on android?
> 
> On Fri, Feb 15, 2019 at 14:55 Jordan Schidlowsky  > wrote:
> Sorry, i'm not sure which script you're referring to!
> 
> 
>> On Feb 15, 2019, at 1:44 PM, Gregory Casamento > > wrote:
>> 
>> Are you talking about how the script configures things?  
>> 
>> On Fri, Feb 15, 2019 at 12:08 Jordan Schidlowsky > > wrote:
>> We will be shipping a large game in a couple weeks on android that is built 
>> on gnustep.   We've been testing very extensively over the past 3-4 months 
>> and things look quite stable (at least on armv7-a).  The game heavily uses 
>> ARC, blocks, libdispatch  Lemme just say the configuration of 
>> gnustep-base, build, and project setup, were not ideal.
>> 
>>> On Feb 15, 2019, at 11:04 AM, Gregory Casamento >> > wrote:
>>> 
>>> The challenge at this point is to get a working app.  
>>> 
>>> On Wed, Feb 13, 2019 at 14:47 Gregory Casamento >> > wrote:
>>> 
>>> Ivan pointed out that I was using the wrong ninja script.  This solved my 
>>> problem.   I am now working on getting base to build properly.
>>> 
>>> GC
>>> 
>>> On Wed, Feb 13, 2019 at 12:21 PM Ivan Vučica >> > wrote:
>>> FTR thank you for that, and for spotting -androideabi16!
>>> 
>>> On Wed, Feb 13, 2019 at 5:20 PM Jordan Schidlowsky >> > wrote:
>>> Agreed, just sharing whats working for us via gradle config.
>>> 
 On Feb 13, 2019, at 11:17 AM, Ivan Vučica >>> > wrote:
 
 Aye; but we should not depend on using Gradle as the end state.
 
 On Wed, Feb 13, 2019 at 5:09 PM Jordan Schidlowsky >>> > wrote:
 Ya you're right,  It should be picked up.  For what it's worth, here's our 
 gradle config, (which ends up passing the correct flags to cmake for 
 building gnustep):
 defaultConfig {
 applicationId "com.noodlecake.ssg4"
 minSdkVersion 21
 targetSdkVersion 28
 versionCode 28
 versionName "1.0.0"
 testInstrumentationRunner 
 "android.support.test.runner.AndroidJUnitRunner"
 externalNativeBuild {
 cmake {
 cppFlags "-std=c++14 -frtti -fexceptions 
 -fconstant-string-class=NSConstantString"
 cFlags "-DANDROID -fconstant-string-class=NSConstantString"
 arguments "-DCMAKE_VERBOSE_MAKEFILE=ON",
 "-DANDROID_STL=c++_static",
 "-DANDROID_DISABLE_FORMAT_STRING_CHECKS=TRUE"
 }
 }
 ndk {
 // Specifies the ABI configurations of your native
 // libraries Gradle should build and package with your APK.
 //abiFilters 'x86', 'x86_64', 'armeabi', 'armeabi-v7a',
 //'arm64-v8a'
 abiFilters 'armeabi-v7a'
 }
 }
 
 
 
> On Feb 13, 2019, at 11:03 AM, Ivan Vučica  > wrote:
> 
> Reading through the toolchain file 
> ,
>  ANDROID_PLATFORM will be calculated from ANDROID_NATIVE_API_LEVEL. So 
> that should not be the issue.
> 
> I'd start by pepper-spraying message() calls in toolchain .cmake file, 
> and in other .cmake files as necessary, too.
> 
> On Wed, Feb 13, 2019 at 5:01 PM Jordan Schidlowsky  > wrote:
> Ah, i didn't see that shell script...  I think 
> -DANDROID_PLATFORM=android-21 (or 23) is what you want there.
> 
> 
>> On Feb 13, 2019, at 10:53 AM, Ivan Vučica > > wrote:
>> 
>> Actually -- it doesn't explain why this is happening, as the shell 
>> script (which I failed to notice Gregory attached) matches what I sent 
>> him. It's using -DANDROID_NATIVE_API_LEVEL=23 which should make it use 
>> ...-androideabi23.
>> 
>> Strange.
>> 
>> On Wed, Feb 13, 2019 at 4:47 PM Ivan Vučica > 

Re: Building on android....

[Gregory Casamento]

The one we were discussing in this thread.  How are you configuring your
app on android?

On Fri, Feb 15, 2019 at 14:55 Jordan Schidlowsky 
wrote:

> Sorry, i'm not sure which script you're referring to!
>
> On Feb 15, 2019, at 1:44 PM, Gregory Casamento 
> wrote:
>
> Are you talking about how the script configures things?
>
> On Fri, Feb 15, 2019 at 12:08 Jordan Schidlowsky 
> wrote:
>
>> We will be shipping a large game in a couple weeks on android that is
>> built on gnustep.   We've been testing very extensively over the past 3-4
>> months and things look quite stable (at least on armv7-a).  The game
>> heavily uses ARC, blocks, libdispatch  Lemme just say the configuration
>> of gnustep-base, build, and project setup, were not ideal.
>>
>> On Feb 15, 2019, at 11:04 AM, Gregory Casamento 
>> wrote:
>>
>> The challenge at this point is to get a working app.
>>
>> On Wed, Feb 13, 2019 at 14:47 Gregory Casamento 
>> wrote:
>>
>>> Ivan pointed out that I was using the wrong ninja script.  This solved
>>> my problem.   I am now working on getting base to build properly.
>>>
>>> GC
>>>
>>> On Wed, Feb 13, 2019 at 12:21 PM Ivan Vučica  wrote:
>>>
 FTR thank you for that, and for spotting -androideabi16!

 On Wed, Feb 13, 2019 at 5:20 PM Jordan Schidlowsky <
 jor...@noodlecake.com> wrote:

> Agreed, just sharing whats working for us via gradle config.
>
> On Feb 13, 2019, at 11:17 AM, Ivan Vučica  wrote:
>
> Aye; but we should not depend on using Gradle as the end state.
>
> On Wed, Feb 13, 2019 at 5:09 PM Jordan Schidlowsky <
> jor...@noodlecake.com> wrote:
>
>> Ya you're right,  It should be picked up.  For what it's worth,
>> here's our gradle config, (which ends up passing the correct flags to 
>> cmake
>> for building gnustep):
>>
>> defaultConfig {
>> applicationId "com.noodlecake.ssg4"
>> minSdkVersion 21
>> targetSdkVersion 28
>> versionCode 28
>> versionName "1.0.0"
>> testInstrumentationRunner 
>> "android.support.test.runner.AndroidJUnitRunner"
>> externalNativeBuild {
>> cmake {
>> cppFlags "-std=c++14 -frtti -fexceptions 
>> -fconstant-string-class=NSConstantString"
>> cFlags "-DANDROID -fconstant-string-class=NSConstantString"
>> arguments "-DCMAKE_VERBOSE_MAKEFILE=ON",
>> "-DANDROID_STL=c++_static",
>> "-DANDROID_DISABLE_FORMAT_STRING_CHECKS=TRUE"
>> }
>> }
>> ndk {
>> // Specifies the ABI configurations of your native
>> // libraries Gradle should build and package with your APK.
>> //abiFilters 'x86', 'x86_64', 'armeabi', 'armeabi-v7a',
>> //'arm64-v8a'
>> abiFilters 'armeabi-v7a'
>> }
>> }
>>
>>
>>
>>
>> On Feb 13, 2019, at 11:03 AM, Ivan Vučica  wrote:
>>
>> Reading through the toolchain file
>> ,
>> ANDROID_PLATFORM will be calculated from ANDROID_NATIVE_API_LEVEL. So 
>> that
>> should not be the issue.
>>
>> I'd start by pepper-spraying message() calls in toolchain .cmake
>> file, and in other .cmake files as necessary, too.
>>
>> On Wed, Feb 13, 2019 at 5:01 PM Jordan Schidlowsky <
>> jor...@noodlecake.com> wrote:
>>
>>> Ah, i didn't see that shell script...  I think
>>> -DANDROID_PLATFORM=android-21 (or 23) is what you want there.
>>>
>>>
>>> On Feb 13, 2019, at 10:53 AM, Ivan Vučica  wrote:
>>>
>>> Actually -- it doesn't explain why this is happening, as the shell
>>> script (which I failed to notice Gregory attached) matches what I sent 
>>> him.
>>> It's using -DANDROID_NATIVE_API_LEVEL=23 which should make it use
>>> ...-androideabi23.
>>>
>>> Strange.
>>>
>>> On Wed, Feb 13, 2019 at 4:47 PM Ivan Vučica  wrote:
>>>
 Ah, that doesn't match what I sent out and makes me feel better ;-)

 On Wed, Feb 13, 2019 at 4:41 PM Jordan Schidlowsky <
 jor...@noodlecake.com> wrote:

> I think this line in his output indicates he's building for API 16:
>
>  --target=armv7-none-linux-androideabi16
>
> On Feb 13, 2019, at 10:07 AM, Ivan Vučica  wrote:
>
> Since Greg mentioned me:
>
> Instructions/commands I came up with and that I sent over to
> Gregory should attempt using API level 23. Totally arbitrarily 
> picked. Use
> of pre-21 API is not happening so not an issue.
>
> Needless to say, building works for me. I don’t ha

Re: Building on android....

[Jordan Schidlowsky]

Sorry, i'm not sure which script you're referring to!

> On Feb 15, 2019, at 1:44 PM, Gregory Casamento  
> wrote:
> 
> Are you talking about how the script configures things?  
> 
> On Fri, Feb 15, 2019 at 12:08 Jordan Schidlowsky  > wrote:
> We will be shipping a large game in a couple weeks on android that is built 
> on gnustep.   We've been testing very extensively over the past 3-4 months 
> and things look quite stable (at least on armv7-a).  The game heavily uses 
> ARC, blocks, libdispatch  Lemme just say the configuration of 
> gnustep-base, build, and project setup, were not ideal.
> 
>> On Feb 15, 2019, at 11:04 AM, Gregory Casamento > > wrote:
>> 
>> The challenge at this point is to get a working app.  
>> 
>> On Wed, Feb 13, 2019 at 14:47 Gregory Casamento > > wrote:
>> 
>> Ivan pointed out that I was using the wrong ninja script.  This solved my 
>> problem.   I am now working on getting base to build properly.
>> 
>> GC
>> 
>> On Wed, Feb 13, 2019 at 12:21 PM Ivan Vučica > > wrote:
>> FTR thank you for that, and for spotting -androideabi16!
>> 
>> On Wed, Feb 13, 2019 at 5:20 PM Jordan Schidlowsky > > wrote:
>> Agreed, just sharing whats working for us via gradle config.
>> 
>>> On Feb 13, 2019, at 11:17 AM, Ivan Vučica >> > wrote:
>>> 
>>> Aye; but we should not depend on using Gradle as the end state.
>>> 
>>> On Wed, Feb 13, 2019 at 5:09 PM Jordan Schidlowsky >> > wrote:
>>> Ya you're right,  It should be picked up.  For what it's worth, here's our 
>>> gradle config, (which ends up passing the correct flags to cmake for 
>>> building gnustep):
>>> defaultConfig {
>>> applicationId "com.noodlecake.ssg4"
>>> minSdkVersion 21
>>> targetSdkVersion 28
>>> versionCode 28
>>> versionName "1.0.0"
>>> testInstrumentationRunner 
>>> "android.support.test.runner.AndroidJUnitRunner"
>>> externalNativeBuild {
>>> cmake {
>>> cppFlags "-std=c++14 -frtti -fexceptions 
>>> -fconstant-string-class=NSConstantString"
>>> cFlags "-DANDROID -fconstant-string-class=NSConstantString"
>>> arguments "-DCMAKE_VERBOSE_MAKEFILE=ON",
>>> "-DANDROID_STL=c++_static",
>>> "-DANDROID_DISABLE_FORMAT_STRING_CHECKS=TRUE"
>>> }
>>> }
>>> ndk {
>>> // Specifies the ABI configurations of your native
>>> // libraries Gradle should build and package with your APK.
>>> //abiFilters 'x86', 'x86_64', 'armeabi', 'armeabi-v7a',
>>> //'arm64-v8a'
>>> abiFilters 'armeabi-v7a'
>>> }
>>> }
>>> 
>>> 
>>> 
 On Feb 13, 2019, at 11:03 AM, Ivan Vučica >>> > wrote:
 
 Reading through the toolchain file 
 ,
  ANDROID_PLATFORM will be calculated from ANDROID_NATIVE_API_LEVEL. So 
 that should not be the issue.
 
 I'd start by pepper-spraying message() calls in toolchain .cmake file, and 
 in other .cmake files as necessary, too.
 
 On Wed, Feb 13, 2019 at 5:01 PM Jordan Schidlowsky >>> > wrote:
 Ah, i didn't see that shell script...  I think 
 -DANDROID_PLATFORM=android-21 (or 23) is what you want there.
 
 
> On Feb 13, 2019, at 10:53 AM, Ivan Vučica  > wrote:
> 
> Actually -- it doesn't explain why this is happening, as the shell script 
> (which I failed to notice Gregory attached) matches what I sent him. It's 
> using -DANDROID_NATIVE_API_LEVEL=23 which should make it use 
> ...-androideabi23.
> 
> Strange.
> 
> On Wed, Feb 13, 2019 at 4:47 PM Ivan Vučica  > wrote:
> Ah, that doesn't match what I sent out and makes me feel better ;-)
> 
> On Wed, Feb 13, 2019 at 4:41 PM Jordan Schidlowsky  > wrote:
> I think this line in his output indicates he's building for API 16:
> 
>  --target=armv7-none-linux-androideabi16 
> 
>> On Feb 13, 2019, at 10:07 AM, Ivan Vučica > > wrote:
>> 
>> Since Greg mentioned me: 
>> 
>> Instructions/commands I came up with and that I sent over to Gregory 
>> should attempt using API level 23. Totally arbitrarily picked. Use of 
>> pre-21 API is not happening so not an issue.
>> 
>> Needless to say, building works for me. I don’t have a self-contained 
>> script to share, but it’s super simplistic and what Greg described (incl 
>> using GUI to install NDK) is w

Re: Building on android....

[Gregory Casamento]

Are you talking about how the script configures things?

On Fri, Feb 15, 2019 at 12:08 Jordan Schidlowsky 
wrote:

> We will be shipping a large game in a couple weeks on android that is
> built on gnustep.   We've been testing very extensively over the past 3-4
> months and things look quite stable (at least on armv7-a).  The game
> heavily uses ARC, blocks, libdispatch  Lemme just say the configuration
> of gnustep-base, build, and project setup, were not ideal.
>
> On Feb 15, 2019, at 11:04 AM, Gregory Casamento 
> wrote:
>
> The challenge at this point is to get a working app.
>
> On Wed, Feb 13, 2019 at 14:47 Gregory Casamento 
> wrote:
>
>> Ivan pointed out that I was using the wrong ninja script.  This solved my
>> problem.   I am now working on getting base to build properly.
>>
>> GC
>>
>> On Wed, Feb 13, 2019 at 12:21 PM Ivan Vučica  wrote:
>>
>>> FTR thank you for that, and for spotting -androideabi16!
>>>
>>> On Wed, Feb 13, 2019 at 5:20 PM Jordan Schidlowsky <
>>> jor...@noodlecake.com> wrote:
>>>
 Agreed, just sharing whats working for us via gradle config.

 On Feb 13, 2019, at 11:17 AM, Ivan Vučica  wrote:

 Aye; but we should not depend on using Gradle as the end state.

 On Wed, Feb 13, 2019 at 5:09 PM Jordan Schidlowsky <
 jor...@noodlecake.com> wrote:

> Ya you're right,  It should be picked up.  For what it's worth, here's
> our gradle config, (which ends up passing the correct flags to cmake for
> building gnustep):
>
> defaultConfig {
> applicationId "com.noodlecake.ssg4"
> minSdkVersion 21
> targetSdkVersion 28
> versionCode 28
> versionName "1.0.0"
> testInstrumentationRunner 
> "android.support.test.runner.AndroidJUnitRunner"
> externalNativeBuild {
> cmake {
> cppFlags "-std=c++14 -frtti -fexceptions 
> -fconstant-string-class=NSConstantString"
> cFlags "-DANDROID -fconstant-string-class=NSConstantString"
> arguments "-DCMAKE_VERBOSE_MAKEFILE=ON",
> "-DANDROID_STL=c++_static",
> "-DANDROID_DISABLE_FORMAT_STRING_CHECKS=TRUE"
> }
> }
> ndk {
> // Specifies the ABI configurations of your native
> // libraries Gradle should build and package with your APK.
> //abiFilters 'x86', 'x86_64', 'armeabi', 'armeabi-v7a',
> //'arm64-v8a'
> abiFilters 'armeabi-v7a'
> }
> }
>
>
>
>
> On Feb 13, 2019, at 11:03 AM, Ivan Vučica  wrote:
>
> Reading through the toolchain file
> ,
> ANDROID_PLATFORM will be calculated from ANDROID_NATIVE_API_LEVEL. So that
> should not be the issue.
>
> I'd start by pepper-spraying message() calls in toolchain .cmake file,
> and in other .cmake files as necessary, too.
>
> On Wed, Feb 13, 2019 at 5:01 PM Jordan Schidlowsky <
> jor...@noodlecake.com> wrote:
>
>> Ah, i didn't see that shell script...  I think
>> -DANDROID_PLATFORM=android-21 (or 23) is what you want there.
>>
>>
>> On Feb 13, 2019, at 10:53 AM, Ivan Vučica  wrote:
>>
>> Actually -- it doesn't explain why this is happening, as the shell
>> script (which I failed to notice Gregory attached) matches what I sent 
>> him.
>> It's using -DANDROID_NATIVE_API_LEVEL=23 which should make it use
>> ...-androideabi23.
>>
>> Strange.
>>
>> On Wed, Feb 13, 2019 at 4:47 PM Ivan Vučica  wrote:
>>
>>> Ah, that doesn't match what I sent out and makes me feel better ;-)
>>>
>>> On Wed, Feb 13, 2019 at 4:41 PM Jordan Schidlowsky <
>>> jor...@noodlecake.com> wrote:
>>>
 I think this line in his output indicates he's building for API 16:

  --target=armv7-none-linux-androideabi16

 On Feb 13, 2019, at 10:07 AM, Ivan Vučica  wrote:

 Since Greg mentioned me:

 Instructions/commands I came up with and that I sent over to
 Gregory should attempt using API level 23. Totally arbitrarily picked. 
 Use
 of pre-21 API is not happening so not an issue.

 Needless to say, building works for me. I don’t have a
 self-contained script to share, but it’s super simplistic and what Greg
 described (incl using GUI to install NDK) is what I did.

 I’m only sure it builds, not that it works, as I am yet to try
 running the code; I don’t have a build script ready for producing an 
 APK
 (the old approach from 2013 and 2014 is a mess and needs to be 
 r

Re: Building on android....

[Jordan Schidlowsky]

We will be shipping a large game in a couple weeks on android that is built on 
gnustep.   We've been testing very extensively over the past 3-4 months and 
things look quite stable (at least on armv7-a).  The game heavily uses ARC, 
blocks, libdispatch  Lemme just say the configuration of gnustep-base, 
build, and project setup, were not ideal.

> On Feb 15, 2019, at 11:04 AM, Gregory Casamento  
> wrote:
> 
> The challenge at this point is to get a working app.  
> 
> On Wed, Feb 13, 2019 at 14:47 Gregory Casamento  > wrote:
> 
> Ivan pointed out that I was using the wrong ninja script.  This solved my 
> problem.   I am now working on getting base to build properly.
> 
> GC
> 
> On Wed, Feb 13, 2019 at 12:21 PM Ivan Vučica  > wrote:
> FTR thank you for that, and for spotting -androideabi16!
> 
> On Wed, Feb 13, 2019 at 5:20 PM Jordan Schidlowsky  > wrote:
> Agreed, just sharing whats working for us via gradle config.
> 
>> On Feb 13, 2019, at 11:17 AM, Ivan Vučica > > wrote:
>> 
>> Aye; but we should not depend on using Gradle as the end state.
>> 
>> On Wed, Feb 13, 2019 at 5:09 PM Jordan Schidlowsky > > wrote:
>> Ya you're right,  It should be picked up.  For what it's worth, here's our 
>> gradle config, (which ends up passing the correct flags to cmake for 
>> building gnustep):
>> defaultConfig {
>> applicationId "com.noodlecake.ssg4"
>> minSdkVersion 21
>> targetSdkVersion 28
>> versionCode 28
>> versionName "1.0.0"
>> testInstrumentationRunner 
>> "android.support.test.runner.AndroidJUnitRunner"
>> externalNativeBuild {
>> cmake {
>> cppFlags "-std=c++14 -frtti -fexceptions 
>> -fconstant-string-class=NSConstantString"
>> cFlags "-DANDROID -fconstant-string-class=NSConstantString"
>> arguments "-DCMAKE_VERBOSE_MAKEFILE=ON",
>> "-DANDROID_STL=c++_static",
>> "-DANDROID_DISABLE_FORMAT_STRING_CHECKS=TRUE"
>> }
>> }
>> ndk {
>> // Specifies the ABI configurations of your native
>> // libraries Gradle should build and package with your APK.
>> //abiFilters 'x86', 'x86_64', 'armeabi', 'armeabi-v7a',
>> //'arm64-v8a'
>> abiFilters 'armeabi-v7a'
>> }
>> }
>> 
>> 
>> 
>>> On Feb 13, 2019, at 11:03 AM, Ivan Vučica >> > wrote:
>>> 
>>> Reading through the toolchain file 
>>> ,
>>>  ANDROID_PLATFORM will be calculated from ANDROID_NATIVE_API_LEVEL. So that 
>>> should not be the issue.
>>> 
>>> I'd start by pepper-spraying message() calls in toolchain .cmake file, and 
>>> in other .cmake files as necessary, too.
>>> 
>>> On Wed, Feb 13, 2019 at 5:01 PM Jordan Schidlowsky >> > wrote:
>>> Ah, i didn't see that shell script...  I think 
>>> -DANDROID_PLATFORM=android-21 (or 23) is what you want there.
>>> 
>>> 
 On Feb 13, 2019, at 10:53 AM, Ivan Vučica >>> > wrote:
 
 Actually -- it doesn't explain why this is happening, as the shell script 
 (which I failed to notice Gregory attached) matches what I sent him. It's 
 using -DANDROID_NATIVE_API_LEVEL=23 which should make it use 
 ...-androideabi23.
 
 Strange.
 
 On Wed, Feb 13, 2019 at 4:47 PM Ivan Vučica >>> > wrote:
 Ah, that doesn't match what I sent out and makes me feel better ;-)
 
 On Wed, Feb 13, 2019 at 4:41 PM Jordan Schidlowsky >>> > wrote:
 I think this line in his output indicates he's building for API 16:
 
  --target=armv7-none-linux-androideabi16 
 
> On Feb 13, 2019, at 10:07 AM, Ivan Vučica  > wrote:
> 
> Since Greg mentioned me: 
> 
> Instructions/commands I came up with and that I sent over to Gregory 
> should attempt using API level 23. Totally arbitrarily picked. Use of 
> pre-21 API is not happening so not an issue.
> 
> Needless to say, building works for me. I don’t have a self-contained 
> script to share, but it’s super simplistic and what Greg described (incl 
> using GUI to install NDK) is what I did.
> 
> I’m only sure it builds, not that it works, as I am yet to try running 
> the code; I don’t have a build script ready for producing an APK (the old 
> approach from 2013 and 2014 is a mess and needs to be reworked).
> 
> On Wed 13 Feb 2019 at 15:34 Jordan Schidlowsky  > wrote:
> I've got some patches but they are pretty ugly and I want to clean 

Re: Building on android....

[Gregory Casamento]

The challenge at this point is to get a working app.

On Wed, Feb 13, 2019 at 14:47 Gregory Casamento 
wrote:

> Ivan pointed out that I was using the wrong ninja script.  This solved my
> problem.   I am now working on getting base to build properly.
>
> GC
>
> On Wed, Feb 13, 2019 at 12:21 PM Ivan Vučica  wrote:
>
>> FTR thank you for that, and for spotting -androideabi16!
>>
>> On Wed, Feb 13, 2019 at 5:20 PM Jordan Schidlowsky 
>> wrote:
>>
>>> Agreed, just sharing whats working for us via gradle config.
>>>
>>> On Feb 13, 2019, at 11:17 AM, Ivan Vučica  wrote:
>>>
>>> Aye; but we should not depend on using Gradle as the end state.
>>>
>>> On Wed, Feb 13, 2019 at 5:09 PM Jordan Schidlowsky <
>>> jor...@noodlecake.com> wrote:
>>>
 Ya you're right,  It should be picked up.  For what it's worth, here's
 our gradle config, (which ends up passing the correct flags to cmake for
 building gnustep):

 defaultConfig {
 applicationId "com.noodlecake.ssg4"
 minSdkVersion 21
 targetSdkVersion 28
 versionCode 28
 versionName "1.0.0"
 testInstrumentationRunner 
 "android.support.test.runner.AndroidJUnitRunner"
 externalNativeBuild {
 cmake {
 cppFlags "-std=c++14 -frtti -fexceptions 
 -fconstant-string-class=NSConstantString"
 cFlags "-DANDROID -fconstant-string-class=NSConstantString"
 arguments "-DCMAKE_VERBOSE_MAKEFILE=ON",
 "-DANDROID_STL=c++_static",
 "-DANDROID_DISABLE_FORMAT_STRING_CHECKS=TRUE"
 }
 }
 ndk {
 // Specifies the ABI configurations of your native
 // libraries Gradle should build and package with your APK.
 //abiFilters 'x86', 'x86_64', 'armeabi', 'armeabi-v7a',
 //'arm64-v8a'
 abiFilters 'armeabi-v7a'
 }
 }




 On Feb 13, 2019, at 11:03 AM, Ivan Vučica  wrote:

 Reading through the toolchain file
 ,
 ANDROID_PLATFORM will be calculated from ANDROID_NATIVE_API_LEVEL. So that
 should not be the issue.

 I'd start by pepper-spraying message() calls in toolchain .cmake file,
 and in other .cmake files as necessary, too.

 On Wed, Feb 13, 2019 at 5:01 PM Jordan Schidlowsky <
 jor...@noodlecake.com> wrote:

> Ah, i didn't see that shell script...  I think
> -DANDROID_PLATFORM=android-21 (or 23) is what you want there.
>
>
> On Feb 13, 2019, at 10:53 AM, Ivan Vučica  wrote:
>
> Actually -- it doesn't explain why this is happening, as the shell
> script (which I failed to notice Gregory attached) matches what I sent 
> him.
> It's using -DANDROID_NATIVE_API_LEVEL=23 which should make it use
> ...-androideabi23.
>
> Strange.
>
> On Wed, Feb 13, 2019 at 4:47 PM Ivan Vučica  wrote:
>
>> Ah, that doesn't match what I sent out and makes me feel better ;-)
>>
>> On Wed, Feb 13, 2019 at 4:41 PM Jordan Schidlowsky <
>> jor...@noodlecake.com> wrote:
>>
>>> I think this line in his output indicates he's building for API 16:
>>>
>>>  --target=armv7-none-linux-androideabi16
>>>
>>> On Feb 13, 2019, at 10:07 AM, Ivan Vučica  wrote:
>>>
>>> Since Greg mentioned me:
>>>
>>> Instructions/commands I came up with and that I sent over to Gregory
>>> should attempt using API level 23. Totally arbitrarily picked. Use of
>>> pre-21 API is not happening so not an issue.
>>>
>>> Needless to say, building works for me. I don’t have a
>>> self-contained script to share, but it’s super simplistic and what Greg
>>> described (incl using GUI to install NDK) is what I did.
>>>
>>> I’m only sure it builds, not that it works, as I am yet to try
>>> running the code; I don’t have a build script ready for producing an APK
>>> (the old approach from 2013 and 2014 is a mess and needs to be 
>>> reworked).
>>>
>>> On Wed 13 Feb 2019 at 15:34 Jordan Schidlowsky <
>>> jor...@noodlecake.com> wrote:
>>>
 I've got some patches but they are pretty ugly and I want to clean
 them up properly before submitting...

 On Feb 13, 2019, at 8:41 AM, Jordan Schidlowsky <
 jor...@noodlecake.com> wrote:

 An NDK app can chose to bundle in a (c++_shared) library in your
 app, or you can link with a static (c++_static) standard library.   
 This is
 actually dependant on what setting you chose for this in your gradle 
 build
 file, as gradle will pass that along to cmake which will link it in.
>

Re: Building on android....

[Gregory Casamento]

Ivan pointed out that I was using the wrong ninja script.  This solved my
problem.   I am now working on getting base to build properly.

GC

On Wed, Feb 13, 2019 at 12:21 PM Ivan Vučica  wrote:

> FTR thank you for that, and for spotting -androideabi16!
>
> On Wed, Feb 13, 2019 at 5:20 PM Jordan Schidlowsky 
> wrote:
>
>> Agreed, just sharing whats working for us via gradle config.
>>
>> On Feb 13, 2019, at 11:17 AM, Ivan Vučica  wrote:
>>
>> Aye; but we should not depend on using Gradle as the end state.
>>
>> On Wed, Feb 13, 2019 at 5:09 PM Jordan Schidlowsky 
>> wrote:
>>
>>> Ya you're right,  It should be picked up.  For what it's worth, here's
>>> our gradle config, (which ends up passing the correct flags to cmake for
>>> building gnustep):
>>>
>>> defaultConfig {
>>> applicationId "com.noodlecake.ssg4"
>>> minSdkVersion 21
>>> targetSdkVersion 28
>>> versionCode 28
>>> versionName "1.0.0"
>>> testInstrumentationRunner 
>>> "android.support.test.runner.AndroidJUnitRunner"
>>> externalNativeBuild {
>>> cmake {
>>> cppFlags "-std=c++14 -frtti -fexceptions 
>>> -fconstant-string-class=NSConstantString"
>>> cFlags "-DANDROID -fconstant-string-class=NSConstantString"
>>> arguments "-DCMAKE_VERBOSE_MAKEFILE=ON",
>>> "-DANDROID_STL=c++_static",
>>> "-DANDROID_DISABLE_FORMAT_STRING_CHECKS=TRUE"
>>> }
>>> }
>>> ndk {
>>> // Specifies the ABI configurations of your native
>>> // libraries Gradle should build and package with your APK.
>>> //abiFilters 'x86', 'x86_64', 'armeabi', 'armeabi-v7a',
>>> //'arm64-v8a'
>>> abiFilters 'armeabi-v7a'
>>> }
>>> }
>>>
>>>
>>>
>>>
>>> On Feb 13, 2019, at 11:03 AM, Ivan Vučica  wrote:
>>>
>>> Reading through the toolchain file
>>> ,
>>> ANDROID_PLATFORM will be calculated from ANDROID_NATIVE_API_LEVEL. So that
>>> should not be the issue.
>>>
>>> I'd start by pepper-spraying message() calls in toolchain .cmake file,
>>> and in other .cmake files as necessary, too.
>>>
>>> On Wed, Feb 13, 2019 at 5:01 PM Jordan Schidlowsky <
>>> jor...@noodlecake.com> wrote:
>>>
 Ah, i didn't see that shell script...  I think
 -DANDROID_PLATFORM=android-21 (or 23) is what you want there.


 On Feb 13, 2019, at 10:53 AM, Ivan Vučica  wrote:

 Actually -- it doesn't explain why this is happening, as the shell
 script (which I failed to notice Gregory attached) matches what I sent him.
 It's using -DANDROID_NATIVE_API_LEVEL=23 which should make it use
 ...-androideabi23.

 Strange.

 On Wed, Feb 13, 2019 at 4:47 PM Ivan Vučica  wrote:

> Ah, that doesn't match what I sent out and makes me feel better ;-)
>
> On Wed, Feb 13, 2019 at 4:41 PM Jordan Schidlowsky <
> jor...@noodlecake.com> wrote:
>
>> I think this line in his output indicates he's building for API 16:
>>
>>  --target=armv7-none-linux-androideabi16
>>
>> On Feb 13, 2019, at 10:07 AM, Ivan Vučica  wrote:
>>
>> Since Greg mentioned me:
>>
>> Instructions/commands I came up with and that I sent over to Gregory
>> should attempt using API level 23. Totally arbitrarily picked. Use of
>> pre-21 API is not happening so not an issue.
>>
>> Needless to say, building works for me. I don’t have a self-contained
>> script to share, but it’s super simplistic and what Greg described (incl
>> using GUI to install NDK) is what I did.
>>
>> I’m only sure it builds, not that it works, as I am yet to try
>> running the code; I don’t have a build script ready for producing an APK
>> (the old approach from 2013 and 2014 is a mess and needs to be reworked).
>>
>> On Wed 13 Feb 2019 at 15:34 Jordan Schidlowsky 
>> wrote:
>>
>>> I've got some patches but they are pretty ugly and I want to clean
>>> them up properly before submitting...
>>>
>>> On Feb 13, 2019, at 8:41 AM, Jordan Schidlowsky <
>>> jor...@noodlecake.com> wrote:
>>>
>>> An NDK app can chose to bundle in a (c++_shared) library in your
>>> app, or you can link with a static (c++_static) standard library.   
>>> This is
>>> actually dependant on what setting you chose for this in your gradle 
>>> build
>>> file, as gradle will pass that along to cmake which will link it in.
>>>
>>> That cxx runtime test doesn't quite work correctly using an android
>>> toolchain.  But if you want to configure your ndk app using c++_static 
>>> you
>>> can remove that test section from CMakeLists.txt and add in manually 
>>> below:
>>>
>>> set(CXXRT_IS_STDLIB tr

Re: Building on android....

[Ivan Vučica]

There are two build.ninja files. One is in
$cmakes_magical_build_root/build.ninja, and the other in
$cmakes_magical_build_root/CMake/build.ninja.

The one in CMake subfolder should not be used.

On Wed, Feb 13, 2019 at 5:03 PM Ivan Vučica  wrote:

> Reading through the toolchain file
> ,
> ANDROID_PLATFORM will be calculated from ANDROID_NATIVE_API_LEVEL. So that
> should not be the issue.
>
> I'd start by pepper-spraying message() calls in toolchain .cmake file, and
> in other .cmake files as necessary, too.
>
> On Wed, Feb 13, 2019 at 5:01 PM Jordan Schidlowsky 
> wrote:
>
>> Ah, i didn't see that shell script...  I think
>> -DANDROID_PLATFORM=android-21 (or 23) is what you want there.
>>
>>
>> On Feb 13, 2019, at 10:53 AM, Ivan Vučica  wrote:
>>
>> Actually -- it doesn't explain why this is happening, as the shell script
>> (which I failed to notice Gregory attached) matches what I sent him. It's
>> using -DANDROID_NATIVE_API_LEVEL=23 which should make it use
>> ...-androideabi23.
>>
>> Strange.
>>
>> On Wed, Feb 13, 2019 at 4:47 PM Ivan Vučica  wrote:
>>
>>> Ah, that doesn't match what I sent out and makes me feel better ;-)
>>>
>>> On Wed, Feb 13, 2019 at 4:41 PM Jordan Schidlowsky <
>>> jor...@noodlecake.com> wrote:
>>>
 I think this line in his output indicates he's building for API 16:

  --target=armv7-none-linux-androideabi16

 On Feb 13, 2019, at 10:07 AM, Ivan Vučica  wrote:

 Since Greg mentioned me:

 Instructions/commands I came up with and that I sent over to Gregory
 should attempt using API level 23. Totally arbitrarily picked. Use of
 pre-21 API is not happening so not an issue.

 Needless to say, building works for me. I don’t have a self-contained
 script to share, but it’s super simplistic and what Greg described (incl
 using GUI to install NDK) is what I did.

 I’m only sure it builds, not that it works, as I am yet to try running
 the code; I don’t have a build script ready for producing an APK (the old
 approach from 2013 and 2014 is a mess and needs to be reworked).

 On Wed 13 Feb 2019 at 15:34 Jordan Schidlowsky 
 wrote:

> I've got some patches but they are pretty ugly and I want to clean
> them up properly before submitting...
>
> On Feb 13, 2019, at 8:41 AM, Jordan Schidlowsky 
> wrote:
>
> An NDK app can chose to bundle in a (c++_shared) library in your app,
> or you can link with a static (c++_static) standard library.   This is
> actually dependant on what setting you chose for this in your gradle build
> file, as gradle will pass that along to cmake which will link it in.
>
> That cxx runtime test doesn't quite work correctly using an android
> toolchain.  But if you want to configure your ndk app using c++_static you
> can remove that test section from CMakeLists.txt and add in manually 
> below:
>
> set(CXXRT_IS_STDLIB true)
> target_link_libraries(objc c++_static stdc++)
>
> I will also note, that I am still thinking about a way to run that
> test suite while cross compiling...
>
>
> On Feb 13, 2019, at 6:41 AM, Gregory Casamento <
> greg.casame...@gmail.com> wrote:
>
> A little more context...  my build environment is a MacPro 2010
> running the latest version of Mojave.  I have downloaded and installed the
> latest of Android studio and installed the latest SDK and NDK using the
> menu under tools and the SDK manager.  The version of the NDK I'm using 
> is 19.0.5232133.
>  I am utterly stumped as to why this is not working.  Also, it seems as
> though Ivan's installation of this is working which seems to indicate that
> this is a configuration issue.
>
> Any input would be appreciated.
>
> On Wed, Feb 13, 2019 at 7:09 AM Gregory Casamento <
> greg.casame...@gmail.com> wrote:
>
>> ### Build libobjc2
>> -- The ASM compiler identification is Clang
>> -- Found assembler:
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
>> -- Check for working C compiler:
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
>> -- Check for working C compiler:
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/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/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
>> -- Check for working CXX compiler:
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
>> -- 

Re: Building on android....

[Ivan Vučica]

FTR thank you for that, and for spotting -androideabi16!

On Wed, Feb 13, 2019 at 5:20 PM Jordan Schidlowsky 
wrote:

> Agreed, just sharing whats working for us via gradle config.
>
> On Feb 13, 2019, at 11:17 AM, Ivan Vučica  wrote:
>
> Aye; but we should not depend on using Gradle as the end state.
>
> On Wed, Feb 13, 2019 at 5:09 PM Jordan Schidlowsky 
> wrote:
>
>> Ya you're right,  It should be picked up.  For what it's worth, here's
>> our gradle config, (which ends up passing the correct flags to cmake for
>> building gnustep):
>>
>> defaultConfig {
>> applicationId "com.noodlecake.ssg4"
>> minSdkVersion 21
>> targetSdkVersion 28
>> versionCode 28
>> versionName "1.0.0"
>> testInstrumentationRunner 
>> "android.support.test.runner.AndroidJUnitRunner"
>> externalNativeBuild {
>> cmake {
>> cppFlags "-std=c++14 -frtti -fexceptions 
>> -fconstant-string-class=NSConstantString"
>> cFlags "-DANDROID -fconstant-string-class=NSConstantString"
>> arguments "-DCMAKE_VERBOSE_MAKEFILE=ON",
>> "-DANDROID_STL=c++_static",
>> "-DANDROID_DISABLE_FORMAT_STRING_CHECKS=TRUE"
>> }
>> }
>> ndk {
>> // Specifies the ABI configurations of your native
>> // libraries Gradle should build and package with your APK.
>> //abiFilters 'x86', 'x86_64', 'armeabi', 'armeabi-v7a',
>> //'arm64-v8a'
>> abiFilters 'armeabi-v7a'
>> }
>> }
>>
>>
>>
>>
>> On Feb 13, 2019, at 11:03 AM, Ivan Vučica  wrote:
>>
>> Reading through the toolchain file
>> ,
>> ANDROID_PLATFORM will be calculated from ANDROID_NATIVE_API_LEVEL. So that
>> should not be the issue.
>>
>> I'd start by pepper-spraying message() calls in toolchain .cmake file,
>> and in other .cmake files as necessary, too.
>>
>> On Wed, Feb 13, 2019 at 5:01 PM Jordan Schidlowsky 
>> wrote:
>>
>>> Ah, i didn't see that shell script...  I think
>>> -DANDROID_PLATFORM=android-21 (or 23) is what you want there.
>>>
>>>
>>> On Feb 13, 2019, at 10:53 AM, Ivan Vučica  wrote:
>>>
>>> Actually -- it doesn't explain why this is happening, as the shell
>>> script (which I failed to notice Gregory attached) matches what I sent him.
>>> It's using -DANDROID_NATIVE_API_LEVEL=23 which should make it use
>>> ...-androideabi23.
>>>
>>> Strange.
>>>
>>> On Wed, Feb 13, 2019 at 4:47 PM Ivan Vučica  wrote:
>>>
 Ah, that doesn't match what I sent out and makes me feel better ;-)

 On Wed, Feb 13, 2019 at 4:41 PM Jordan Schidlowsky <
 jor...@noodlecake.com> wrote:

> I think this line in his output indicates he's building for API 16:
>
>  --target=armv7-none-linux-androideabi16
>
> On Feb 13, 2019, at 10:07 AM, Ivan Vučica  wrote:
>
> Since Greg mentioned me:
>
> Instructions/commands I came up with and that I sent over to Gregory
> should attempt using API level 23. Totally arbitrarily picked. Use of
> pre-21 API is not happening so not an issue.
>
> Needless to say, building works for me. I don’t have a self-contained
> script to share, but it’s super simplistic and what Greg described (incl
> using GUI to install NDK) is what I did.
>
> I’m only sure it builds, not that it works, as I am yet to try running
> the code; I don’t have a build script ready for producing an APK (the old
> approach from 2013 and 2014 is a mess and needs to be reworked).
>
> On Wed 13 Feb 2019 at 15:34 Jordan Schidlowsky 
> wrote:
>
>> I've got some patches but they are pretty ugly and I want to clean
>> them up properly before submitting...
>>
>> On Feb 13, 2019, at 8:41 AM, Jordan Schidlowsky <
>> jor...@noodlecake.com> wrote:
>>
>> An NDK app can chose to bundle in a (c++_shared) library in your app,
>> or you can link with a static (c++_static) standard library.   This is
>> actually dependant on what setting you chose for this in your gradle 
>> build
>> file, as gradle will pass that along to cmake which will link it in.
>>
>> That cxx runtime test doesn't quite work correctly using an android
>> toolchain.  But if you want to configure your ndk app using c++_static 
>> you
>> can remove that test section from CMakeLists.txt and add in manually 
>> below:
>>
>> set(CXXRT_IS_STDLIB true)
>> target_link_libraries(objc c++_static stdc++)
>>
>> I will also note, that I am still thinking about a way to run that
>> test suite while cross compiling...
>>
>>
>> On Feb 13, 2019, at 6:41 AM, Gregory Casamento <
>> greg.casame...@gmail.com> wrote:
>>
>> A little more context...  my build environment is a MacPro 2010
>> running the latest version of Mojave.  I have downloaded and installed 
>> the
>> latest of Android studio and i

Re: Building on android....

[Jordan Schidlowsky]

Agreed, just sharing whats working for us via gradle config.

> On Feb 13, 2019, at 11:17 AM, Ivan Vučica  wrote:
> 
> Aye; but we should not depend on using Gradle as the end state.
> 
> On Wed, Feb 13, 2019 at 5:09 PM Jordan Schidlowsky  > wrote:
> Ya you're right,  It should be picked up.  For what it's worth, here's our 
> gradle config, (which ends up passing the correct flags to cmake for building 
> gnustep):
> defaultConfig {
> applicationId "com.noodlecake.ssg4"
> minSdkVersion 21
> targetSdkVersion 28
> versionCode 28
> versionName "1.0.0"
> testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
> externalNativeBuild {
> cmake {
> cppFlags "-std=c++14 -frtti -fexceptions 
> -fconstant-string-class=NSConstantString"
> cFlags "-DANDROID -fconstant-string-class=NSConstantString"
> arguments "-DCMAKE_VERBOSE_MAKEFILE=ON",
> "-DANDROID_STL=c++_static",
> "-DANDROID_DISABLE_FORMAT_STRING_CHECKS=TRUE"
> }
> }
> ndk {
> // Specifies the ABI configurations of your native
> // libraries Gradle should build and package with your APK.
> //abiFilters 'x86', 'x86_64', 'armeabi', 'armeabi-v7a',
> //'arm64-v8a'
> abiFilters 'armeabi-v7a'
> }
> }
> 
> 
> 
>> On Feb 13, 2019, at 11:03 AM, Ivan Vučica > > wrote:
>> 
>> Reading through the toolchain file 
>> ,
>>  ANDROID_PLATFORM will be calculated from ANDROID_NATIVE_API_LEVEL. So that 
>> should not be the issue.
>> 
>> I'd start by pepper-spraying message() calls in toolchain .cmake file, and 
>> in other .cmake files as necessary, too.
>> 
>> On Wed, Feb 13, 2019 at 5:01 PM Jordan Schidlowsky > > wrote:
>> Ah, i didn't see that shell script...  I think -DANDROID_PLATFORM=android-21 
>> (or 23) is what you want there.
>> 
>> 
>>> On Feb 13, 2019, at 10:53 AM, Ivan Vučica >> > wrote:
>>> 
>>> Actually -- it doesn't explain why this is happening, as the shell script 
>>> (which I failed to notice Gregory attached) matches what I sent him. It's 
>>> using -DANDROID_NATIVE_API_LEVEL=23 which should make it use 
>>> ...-androideabi23.
>>> 
>>> Strange.
>>> 
>>> On Wed, Feb 13, 2019 at 4:47 PM Ivan Vučica >> > wrote:
>>> Ah, that doesn't match what I sent out and makes me feel better ;-)
>>> 
>>> On Wed, Feb 13, 2019 at 4:41 PM Jordan Schidlowsky >> > wrote:
>>> I think this line in his output indicates he's building for API 16:
>>> 
>>>  --target=armv7-none-linux-androideabi16 
>>> 
 On Feb 13, 2019, at 10:07 AM, Ivan Vučica >>> > wrote:
 
 Since Greg mentioned me: 
 
 Instructions/commands I came up with and that I sent over to Gregory 
 should attempt using API level 23. Totally arbitrarily picked. Use of 
 pre-21 API is not happening so not an issue.
 
 Needless to say, building works for me. I don’t have a self-contained 
 script to share, but it’s super simplistic and what Greg described (incl 
 using GUI to install NDK) is what I did.
 
 I’m only sure it builds, not that it works, as I am yet to try running the 
 code; I don’t have a build script ready for producing an APK (the old 
 approach from 2013 and 2014 is a mess and needs to be reworked).
 
 On Wed 13 Feb 2019 at 15:34 Jordan Schidlowsky >>> > wrote:
 I've got some patches but they are pretty ugly and I want to clean them up 
 properly before submitting...
 
 
> On Feb 13, 2019, at 8:41 AM, Jordan Schidlowsky  > wrote:
> 
> An NDK app can chose to bundle in a (c++_shared) library in your app, or 
> you can link with a static (c++_static) standard library.   This is 
> actually dependant on what setting you chose for this in your gradle 
> build file, as gradle will pass that along to cmake which will link it 
> in.  
> 
> That cxx runtime test doesn't quite work correctly using an android 
> toolchain.  But if you want to configure your ndk app using c++_static 
> you can remove that test section from CMakeLists.txt and add in manually 
> below:
> 
> set(CXXRT_IS_STDLIB true)
> target_link_libraries(objc c++_static stdc++)
> 
> I will also note, that I am still thinking about a way to run that test 
> suite while cross compiling... 
> 
> 
>> On Feb 13, 2019, at 6:41 AM, Gregory Casamento > > wrote:
>> 
>> 
>> A little more context...  my build environment is a MacPro 2010 running 
>> the latest version of Mojave.  I have downloaded and installed the 

Re: Building on android....

[Ivan Vučica]

Aye; but we should not depend on using Gradle as the end state.

On Wed, Feb 13, 2019 at 5:09 PM Jordan Schidlowsky 
wrote:

> Ya you're right,  It should be picked up.  For what it's worth, here's our
> gradle config, (which ends up passing the correct flags to cmake for
> building gnustep):
>
> defaultConfig {
> applicationId "com.noodlecake.ssg4"
> minSdkVersion 21
> targetSdkVersion 28
> versionCode 28
> versionName "1.0.0"
> testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
> externalNativeBuild {
> cmake {
> cppFlags "-std=c++14 -frtti -fexceptions 
> -fconstant-string-class=NSConstantString"
> cFlags "-DANDROID -fconstant-string-class=NSConstantString"
> arguments "-DCMAKE_VERBOSE_MAKEFILE=ON",
> "-DANDROID_STL=c++_static",
> "-DANDROID_DISABLE_FORMAT_STRING_CHECKS=TRUE"
> }
> }
> ndk {
> // Specifies the ABI configurations of your native
> // libraries Gradle should build and package with your APK.
> //abiFilters 'x86', 'x86_64', 'armeabi', 'armeabi-v7a',
> //'arm64-v8a'
> abiFilters 'armeabi-v7a'
> }
> }
>
>
>
>
> On Feb 13, 2019, at 11:03 AM, Ivan Vučica  wrote:
>
> Reading through the toolchain file
> ,
> ANDROID_PLATFORM will be calculated from ANDROID_NATIVE_API_LEVEL. So that
> should not be the issue.
>
> I'd start by pepper-spraying message() calls in toolchain .cmake file, and
> in other .cmake files as necessary, too.
>
> On Wed, Feb 13, 2019 at 5:01 PM Jordan Schidlowsky 
> wrote:
>
>> Ah, i didn't see that shell script...  I think
>> -DANDROID_PLATFORM=android-21 (or 23) is what you want there.
>>
>>
>> On Feb 13, 2019, at 10:53 AM, Ivan Vučica  wrote:
>>
>> Actually -- it doesn't explain why this is happening, as the shell script
>> (which I failed to notice Gregory attached) matches what I sent him. It's
>> using -DANDROID_NATIVE_API_LEVEL=23 which should make it use
>> ...-androideabi23.
>>
>> Strange.
>>
>> On Wed, Feb 13, 2019 at 4:47 PM Ivan Vučica  wrote:
>>
>>> Ah, that doesn't match what I sent out and makes me feel better ;-)
>>>
>>> On Wed, Feb 13, 2019 at 4:41 PM Jordan Schidlowsky <
>>> jor...@noodlecake.com> wrote:
>>>
 I think this line in his output indicates he's building for API 16:

  --target=armv7-none-linux-androideabi16

 On Feb 13, 2019, at 10:07 AM, Ivan Vučica  wrote:

 Since Greg mentioned me:

 Instructions/commands I came up with and that I sent over to Gregory
 should attempt using API level 23. Totally arbitrarily picked. Use of
 pre-21 API is not happening so not an issue.

 Needless to say, building works for me. I don’t have a self-contained
 script to share, but it’s super simplistic and what Greg described (incl
 using GUI to install NDK) is what I did.

 I’m only sure it builds, not that it works, as I am yet to try running
 the code; I don’t have a build script ready for producing an APK (the old
 approach from 2013 and 2014 is a mess and needs to be reworked).

 On Wed 13 Feb 2019 at 15:34 Jordan Schidlowsky 
 wrote:

> I've got some patches but they are pretty ugly and I want to clean
> them up properly before submitting...
>
> On Feb 13, 2019, at 8:41 AM, Jordan Schidlowsky 
> wrote:
>
> An NDK app can chose to bundle in a (c++_shared) library in your app,
> or you can link with a static (c++_static) standard library.   This is
> actually dependant on what setting you chose for this in your gradle build
> file, as gradle will pass that along to cmake which will link it in.
>
> That cxx runtime test doesn't quite work correctly using an android
> toolchain.  But if you want to configure your ndk app using c++_static you
> can remove that test section from CMakeLists.txt and add in manually 
> below:
>
> set(CXXRT_IS_STDLIB true)
> target_link_libraries(objc c++_static stdc++)
>
> I will also note, that I am still thinking about a way to run that
> test suite while cross compiling...
>
>
> On Feb 13, 2019, at 6:41 AM, Gregory Casamento <
> greg.casame...@gmail.com> wrote:
>
> A little more context...  my build environment is a MacPro 2010
> running the latest version of Mojave.  I have downloaded and installed the
> latest of Android studio and installed the latest SDK and NDK using the
> menu under tools and the SDK manager.  The version of the NDK I'm using 
> is 19.0.5232133.
>  I am utterly stumped as to why this is not working.  Also, it seems as
> though Ivan's installation of this is working which seems to indicate that
> this is a configuration issue.
>
> Any input would be appreciated.
>
> On Wed, Feb 13, 201

Re: Building on android....

[Ivan Vučica]

Ah, that doesn't match what I sent out and makes me feel better ;-)

On Wed, Feb 13, 2019 at 4:41 PM Jordan Schidlowsky 
wrote:

> I think this line in his output indicates he's building for API 16:
>
>  --target=armv7-none-linux-androideabi16
>
> On Feb 13, 2019, at 10:07 AM, Ivan Vučica  wrote:
>
> Since Greg mentioned me:
>
> Instructions/commands I came up with and that I sent over to Gregory
> should attempt using API level 23. Totally arbitrarily picked. Use of
> pre-21 API is not happening so not an issue.
>
> Needless to say, building works for me. I don’t have a self-contained
> script to share, but it’s super simplistic and what Greg described (incl
> using GUI to install NDK) is what I did.
>
> I’m only sure it builds, not that it works, as I am yet to try running the
> code; I don’t have a build script ready for producing an APK (the old
> approach from 2013 and 2014 is a mess and needs to be reworked).
>
> On Wed 13 Feb 2019 at 15:34 Jordan Schidlowsky 
> wrote:
>
>> I've got some patches but they are pretty ugly and I want to clean them
>> up properly before submitting...
>>
>> On Feb 13, 2019, at 8:41 AM, Jordan Schidlowsky 
>> wrote:
>>
>> An NDK app can chose to bundle in a (c++_shared) library in your app, or
>> you can link with a static (c++_static) standard library.   This is
>> actually dependant on what setting you chose for this in your gradle build
>> file, as gradle will pass that along to cmake which will link it in.
>>
>> That cxx runtime test doesn't quite work correctly using an android
>> toolchain.  But if you want to configure your ndk app using c++_static you
>> can remove that test section from CMakeLists.txt and add in manually below:
>>
>> set(CXXRT_IS_STDLIB true)
>> target_link_libraries(objc c++_static stdc++)
>>
>> I will also note, that I am still thinking about a way to run that test
>> suite while cross compiling...
>>
>>
>> On Feb 13, 2019, at 6:41 AM, Gregory Casamento 
>> wrote:
>>
>> A little more context...  my build environment is a MacPro 2010 running
>> the latest version of Mojave.  I have downloaded and installed the latest
>> of Android studio and installed the latest SDK and NDK using the menu under
>> tools and the SDK manager.  The version of the NDK I'm using is 19.0.5232133.
>>  I am utterly stumped as to why this is not working.  Also, it seems as
>> though Ivan's installation of this is working which seems to indicate that
>> this is a configuration issue.
>>
>> Any input would be appreciated.
>>
>> On Wed, Feb 13, 2019 at 7:09 AM Gregory Casamento <
>> greg.casame...@gmail.com> wrote:
>>
>>> ### Build libobjc2
>>> -- The ASM compiler identification is Clang
>>> -- Found assembler:
>>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
>>> -- Check for working C compiler:
>>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
>>> -- Check for working C compiler:
>>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/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/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
>>> -- Check for working CXX compiler:
>>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
>>> -- works
>>> -- Detecting CXX compiler ABI info
>>> -- Detecting CXX compiler ABI info - done
>>> -- Detecting CXX compile features
>>> -- Detecting CXX compile features - done
>>> -- Testing C++ interop
>>> -- Testing C++ standard library
>>> -- No useable C++ runtime found
>>> -- Looking for pthread.h
>>> -- Looking for pthread.h - found
>>> -- Looking for pthread_create
>>> -- Looking for pthread_create - found
>>> -- Found Threads: TRUE
>>> -- GNUstep install type set to NONE
>>> -- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES
>>> -- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES - Success
>>> -- Configuring done
>>> -- Generating done
>>> -- Build files have been written to:
>>> /Users/heron/Development/Algoriddim/gnustep-toolchain/gnustep-android/gnustep/libobjc2/build
>>>
>>> /Users/heron/Development/Algoriddim/gnustep-toolchain/gnustep-android/gnustep/libobjc2/build/CMake
>>> [1/1] Linking CXX executable test_cxx_runtime
>>> FAILED: test_cxx_runtime
>>> : &&
>>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
>>> --target=armv7-none-linux-androideabi16
>>> --gcc-toolchain=/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64
>>>   --sysroot
>>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/sysroot
>>> -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables
>>> -fstack-protector-strong -no-canonical-prefixes -mfpu=vfp

Re: Building on android....

[Jordan Schidlowsky]

Ah, i didn't see that shell script...  I think -DANDROID_PLATFORM=android-21 
(or 23) is what you want there.


> On Feb 13, 2019, at 10:53 AM, Ivan Vučica  wrote:
> 
> Actually -- it doesn't explain why this is happening, as the shell script 
> (which I failed to notice Gregory attached) matches what I sent him. It's 
> using -DANDROID_NATIVE_API_LEVEL=23 which should make it use 
> ...-androideabi23.
> 
> Strange.
> 
> On Wed, Feb 13, 2019 at 4:47 PM Ivan Vučica  > wrote:
> Ah, that doesn't match what I sent out and makes me feel better ;-)
> 
> On Wed, Feb 13, 2019 at 4:41 PM Jordan Schidlowsky  > wrote:
> I think this line in his output indicates he's building for API 16:
> 
>  --target=armv7-none-linux-androideabi16 
> 
>> On Feb 13, 2019, at 10:07 AM, Ivan Vučica > > wrote:
>> 
>> Since Greg mentioned me: 
>> 
>> Instructions/commands I came up with and that I sent over to Gregory should 
>> attempt using API level 23. Totally arbitrarily picked. Use of pre-21 API is 
>> not happening so not an issue.
>> 
>> Needless to say, building works for me. I don’t have a self-contained script 
>> to share, but it’s super simplistic and what Greg described (incl using GUI 
>> to install NDK) is what I did.
>> 
>> I’m only sure it builds, not that it works, as I am yet to try running the 
>> code; I don’t have a build script ready for producing an APK (the old 
>> approach from 2013 and 2014 is a mess and needs to be reworked).
>> 
>> On Wed 13 Feb 2019 at 15:34 Jordan Schidlowsky > > wrote:
>> I've got some patches but they are pretty ugly and I want to clean them up 
>> properly before submitting...
>> 
>> 
>>> On Feb 13, 2019, at 8:41 AM, Jordan Schidlowsky >> > wrote:
>>> 
>>> An NDK app can chose to bundle in a (c++_shared) library in your app, or 
>>> you can link with a static (c++_static) standard library.   This is 
>>> actually dependant on what setting you chose for this in your gradle build 
>>> file, as gradle will pass that along to cmake which will link it in.  
>>> 
>>> That cxx runtime test doesn't quite work correctly using an android 
>>> toolchain.  But if you want to configure your ndk app using c++_static you 
>>> can remove that test section from CMakeLists.txt and add in manually below:
>>> 
>>> set(CXXRT_IS_STDLIB true)
>>> target_link_libraries(objc c++_static stdc++)
>>> 
>>> I will also note, that I am still thinking about a way to run that test 
>>> suite while cross compiling... 
>>> 
>>> 
 On Feb 13, 2019, at 6:41 AM, Gregory Casamento >>> > wrote:
 
 
 A little more context...  my build environment is a MacPro 2010 running 
 the latest version of Mojave.  I have downloaded and installed the latest 
 of Android studio and installed the latest SDK and NDK using the menu 
 under tools and the SDK manager.  The version of the NDK I'm using is 
 19.0.5232133.   I am utterly stumped as to why this is not working.  Also, 
 it seems as though Ivan's installation of this is working which seems to 
 indicate that this is a configuration issue.
 
 Any input would be appreciated.
 
 On Wed, Feb 13, 2019 at 7:09 AM Gregory Casamento 
 mailto:greg.casame...@gmail.com>> wrote:
 
 ### Build libobjc2
 -- The ASM compiler identification is Clang
 -- Found assembler: 
 /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
 -- Check for working C compiler: 
 /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
 -- Check for working C compiler: 
 /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/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/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
 -- Check for working CXX compiler: 
 /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
  -- works
 -- Detecting CXX compiler ABI info
 -- Detecting CXX compiler ABI info - done
 -- Detecting CXX compile features
 -- Detecting CXX compile features - done
 -- Testing C++ interop
 -- Testing C++ standard library
 -- No useable C++ runtime found
 -- Looking for pthread.h
 -- Looking for pthread.h - found
 -- Looking for pthread_create
 -- Looking for pthread_create - found
 -- Found Threads: TRUE  
 -- GNUstep install type set to NONE
 -- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES
 -- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES - Success
 -- Configuring done
 -- G

Re: Building on android....

[Ivan Vučica]

Reading through the toolchain file
,
ANDROID_PLATFORM will be calculated from ANDROID_NATIVE_API_LEVEL. So that
should not be the issue.

I'd start by pepper-spraying message() calls in toolchain .cmake file, and
in other .cmake files as necessary, too.

On Wed, Feb 13, 2019 at 5:01 PM Jordan Schidlowsky 
wrote:

> Ah, i didn't see that shell script...  I think
> -DANDROID_PLATFORM=android-21 (or 23) is what you want there.
>
>
> On Feb 13, 2019, at 10:53 AM, Ivan Vučica  wrote:
>
> Actually -- it doesn't explain why this is happening, as the shell script
> (which I failed to notice Gregory attached) matches what I sent him. It's
> using -DANDROID_NATIVE_API_LEVEL=23 which should make it use
> ...-androideabi23.
>
> Strange.
>
> On Wed, Feb 13, 2019 at 4:47 PM Ivan Vučica  wrote:
>
>> Ah, that doesn't match what I sent out and makes me feel better ;-)
>>
>> On Wed, Feb 13, 2019 at 4:41 PM Jordan Schidlowsky 
>> wrote:
>>
>>> I think this line in his output indicates he's building for API 16:
>>>
>>>  --target=armv7-none-linux-androideabi16
>>>
>>> On Feb 13, 2019, at 10:07 AM, Ivan Vučica  wrote:
>>>
>>> Since Greg mentioned me:
>>>
>>> Instructions/commands I came up with and that I sent over to Gregory
>>> should attempt using API level 23. Totally arbitrarily picked. Use of
>>> pre-21 API is not happening so not an issue.
>>>
>>> Needless to say, building works for me. I don’t have a self-contained
>>> script to share, but it’s super simplistic and what Greg described (incl
>>> using GUI to install NDK) is what I did.
>>>
>>> I’m only sure it builds, not that it works, as I am yet to try running
>>> the code; I don’t have a build script ready for producing an APK (the old
>>> approach from 2013 and 2014 is a mess and needs to be reworked).
>>>
>>> On Wed 13 Feb 2019 at 15:34 Jordan Schidlowsky 
>>> wrote:
>>>
 I've got some patches but they are pretty ugly and I want to clean them
 up properly before submitting...

 On Feb 13, 2019, at 8:41 AM, Jordan Schidlowsky 
 wrote:

 An NDK app can chose to bundle in a (c++_shared) library in your app,
 or you can link with a static (c++_static) standard library.   This is
 actually dependant on what setting you chose for this in your gradle build
 file, as gradle will pass that along to cmake which will link it in.

 That cxx runtime test doesn't quite work correctly using an android
 toolchain.  But if you want to configure your ndk app using c++_static you
 can remove that test section from CMakeLists.txt and add in manually below:

 set(CXXRT_IS_STDLIB true)
 target_link_libraries(objc c++_static stdc++)

 I will also note, that I am still thinking about a way to run that test
 suite while cross compiling...


 On Feb 13, 2019, at 6:41 AM, Gregory Casamento <
 greg.casame...@gmail.com> wrote:

 A little more context...  my build environment is a MacPro 2010 running
 the latest version of Mojave.  I have downloaded and installed the latest
 of Android studio and installed the latest SDK and NDK using the menu under
 tools and the SDK manager.  The version of the NDK I'm using is 
 19.0.5232133.
  I am utterly stumped as to why this is not working.  Also, it seems as
 though Ivan's installation of this is working which seems to indicate that
 this is a configuration issue.

 Any input would be appreciated.

 On Wed, Feb 13, 2019 at 7:09 AM Gregory Casamento <
 greg.casame...@gmail.com> wrote:

> ### Build libobjc2
> -- The ASM compiler identification is Clang
> -- Found assembler:
> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
> -- Check for working C compiler:
> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
> -- Check for working C compiler:
> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/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/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
> -- Check for working CXX compiler:
> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
> -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Testing C++ interop
> -- Testing C++ standard library
> -- No useable C++ runtime found
> -- Looking for pthread.h
> -- Looking for pthread.h - found
> -- Looking for pthread_create
>

Re: Building on android....

[Jordan Schidlowsky]

Ya you're right,  It should be picked up.  For what it's worth, here's our 
gradle config, (which ends up passing the correct flags to cmake for building 
gnustep):
defaultConfig {
applicationId "com.noodlecake.ssg4"
minSdkVersion 21
targetSdkVersion 28
versionCode 28
versionName "1.0.0"
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
externalNativeBuild {
cmake {
cppFlags "-std=c++14 -frtti -fexceptions 
-fconstant-string-class=NSConstantString"
cFlags "-DANDROID -fconstant-string-class=NSConstantString"
arguments "-DCMAKE_VERBOSE_MAKEFILE=ON",
"-DANDROID_STL=c++_static",
"-DANDROID_DISABLE_FORMAT_STRING_CHECKS=TRUE"
}
}
ndk {
// Specifies the ABI configurations of your native
// libraries Gradle should build and package with your APK.
//abiFilters 'x86', 'x86_64', 'armeabi', 'armeabi-v7a',
//'arm64-v8a'
abiFilters 'armeabi-v7a'
}
}



> On Feb 13, 2019, at 11:03 AM, Ivan Vučica  wrote:
> 
> Reading through the toolchain file 
> ,
>  ANDROID_PLATFORM will be calculated from ANDROID_NATIVE_API_LEVEL. So that 
> should not be the issue.
> 
> I'd start by pepper-spraying message() calls in toolchain .cmake file, and in 
> other .cmake files as necessary, too.
> 
> On Wed, Feb 13, 2019 at 5:01 PM Jordan Schidlowsky  > wrote:
> Ah, i didn't see that shell script...  I think -DANDROID_PLATFORM=android-21 
> (or 23) is what you want there.
> 
> 
>> On Feb 13, 2019, at 10:53 AM, Ivan Vučica > > wrote:
>> 
>> Actually -- it doesn't explain why this is happening, as the shell script 
>> (which I failed to notice Gregory attached) matches what I sent him. It's 
>> using -DANDROID_NATIVE_API_LEVEL=23 which should make it use 
>> ...-androideabi23.
>> 
>> Strange.
>> 
>> On Wed, Feb 13, 2019 at 4:47 PM Ivan Vučica > > wrote:
>> Ah, that doesn't match what I sent out and makes me feel better ;-)
>> 
>> On Wed, Feb 13, 2019 at 4:41 PM Jordan Schidlowsky > > wrote:
>> I think this line in his output indicates he's building for API 16:
>> 
>>  --target=armv7-none-linux-androideabi16 
>> 
>>> On Feb 13, 2019, at 10:07 AM, Ivan Vučica >> > wrote:
>>> 
>>> Since Greg mentioned me: 
>>> 
>>> Instructions/commands I came up with and that I sent over to Gregory should 
>>> attempt using API level 23. Totally arbitrarily picked. Use of pre-21 API 
>>> is not happening so not an issue.
>>> 
>>> Needless to say, building works for me. I don’t have a self-contained 
>>> script to share, but it’s super simplistic and what Greg described (incl 
>>> using GUI to install NDK) is what I did.
>>> 
>>> I’m only sure it builds, not that it works, as I am yet to try running the 
>>> code; I don’t have a build script ready for producing an APK (the old 
>>> approach from 2013 and 2014 is a mess and needs to be reworked).
>>> 
>>> On Wed 13 Feb 2019 at 15:34 Jordan Schidlowsky >> > wrote:
>>> I've got some patches but they are pretty ugly and I want to clean them up 
>>> properly before submitting...
>>> 
>>> 
 On Feb 13, 2019, at 8:41 AM, Jordan Schidlowsky >>> > wrote:
 
 An NDK app can chose to bundle in a (c++_shared) library in your app, or 
 you can link with a static (c++_static) standard library.   This is 
 actually dependant on what setting you chose for this in your gradle build 
 file, as gradle will pass that along to cmake which will link it in.  
 
 That cxx runtime test doesn't quite work correctly using an android 
 toolchain.  But if you want to configure your ndk app using c++_static you 
 can remove that test section from CMakeLists.txt and add in manually below:
 
 set(CXXRT_IS_STDLIB true)
 target_link_libraries(objc c++_static stdc++)
 
 I will also note, that I am still thinking about a way to run that test 
 suite while cross compiling... 
 
 
> On Feb 13, 2019, at 6:41 AM, Gregory Casamento  > wrote:
> 
> 
> A little more context...  my build environment is a MacPro 2010 running 
> the latest version of Mojave.  I have downloaded and installed the latest 
> of Android studio and installed the latest SDK and NDK using the menu 
> under tools and the SDK manager.  The version of the NDK I'm using is 
> 19.0.5232133.   I am utterly stumped as to why this is not working.  
> Also, it seems as though Ivan's installation of this is working which 
> seems to indicate that this is a configuration issue.
> 
> Any input would be appreciated.
> 
> On Wed, Feb 13, 2019 at 7:09 AM G

Re: Building on android....

[Ivan Vučica]

Actually -- it doesn't explain why this is happening, as the shell script
(which I failed to notice Gregory attached) matches what I sent him. It's
using -DANDROID_NATIVE_API_LEVEL=23 which should make it use
...-androideabi23.

Strange.

On Wed, Feb 13, 2019 at 4:47 PM Ivan Vučica  wrote:

> Ah, that doesn't match what I sent out and makes me feel better ;-)
>
> On Wed, Feb 13, 2019 at 4:41 PM Jordan Schidlowsky 
> wrote:
>
>> I think this line in his output indicates he's building for API 16:
>>
>>  --target=armv7-none-linux-androideabi16
>>
>> On Feb 13, 2019, at 10:07 AM, Ivan Vučica  wrote:
>>
>> Since Greg mentioned me:
>>
>> Instructions/commands I came up with and that I sent over to Gregory
>> should attempt using API level 23. Totally arbitrarily picked. Use of
>> pre-21 API is not happening so not an issue.
>>
>> Needless to say, building works for me. I don’t have a self-contained
>> script to share, but it’s super simplistic and what Greg described (incl
>> using GUI to install NDK) is what I did.
>>
>> I’m only sure it builds, not that it works, as I am yet to try running
>> the code; I don’t have a build script ready for producing an APK (the old
>> approach from 2013 and 2014 is a mess and needs to be reworked).
>>
>> On Wed 13 Feb 2019 at 15:34 Jordan Schidlowsky 
>> wrote:
>>
>>> I've got some patches but they are pretty ugly and I want to clean them
>>> up properly before submitting...
>>>
>>> On Feb 13, 2019, at 8:41 AM, Jordan Schidlowsky 
>>> wrote:
>>>
>>> An NDK app can chose to bundle in a (c++_shared) library in your app, or
>>> you can link with a static (c++_static) standard library.   This is
>>> actually dependant on what setting you chose for this in your gradle build
>>> file, as gradle will pass that along to cmake which will link it in.
>>>
>>> That cxx runtime test doesn't quite work correctly using an android
>>> toolchain.  But if you want to configure your ndk app using c++_static you
>>> can remove that test section from CMakeLists.txt and add in manually below:
>>>
>>> set(CXXRT_IS_STDLIB true)
>>> target_link_libraries(objc c++_static stdc++)
>>>
>>> I will also note, that I am still thinking about a way to run that test
>>> suite while cross compiling...
>>>
>>>
>>> On Feb 13, 2019, at 6:41 AM, Gregory Casamento 
>>> wrote:
>>>
>>> A little more context...  my build environment is a MacPro 2010 running
>>> the latest version of Mojave.  I have downloaded and installed the latest
>>> of Android studio and installed the latest SDK and NDK using the menu under
>>> tools and the SDK manager.  The version of the NDK I'm using is 
>>> 19.0.5232133.
>>>  I am utterly stumped as to why this is not working.  Also, it seems as
>>> though Ivan's installation of this is working which seems to indicate that
>>> this is a configuration issue.
>>>
>>> Any input would be appreciated.
>>>
>>> On Wed, Feb 13, 2019 at 7:09 AM Gregory Casamento <
>>> greg.casame...@gmail.com> wrote:
>>>
 ### Build libobjc2
 -- The ASM compiler identification is Clang
 -- Found assembler:
 /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
 -- Check for working C compiler:
 /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
 -- Check for working C compiler:
 /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/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/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
 -- Check for working CXX compiler:
 /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
 -- works
 -- Detecting CXX compiler ABI info
 -- Detecting CXX compiler ABI info - done
 -- Detecting CXX compile features
 -- Detecting CXX compile features - done
 -- Testing C++ interop
 -- Testing C++ standard library
 -- No useable C++ runtime found
 -- Looking for pthread.h
 -- Looking for pthread.h - found
 -- Looking for pthread_create
 -- Looking for pthread_create - found
 -- Found Threads: TRUE
 -- GNUstep install type set to NONE
 -- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES
 -- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES - Success
 -- Configuring done
 -- Generating done
 -- Build files have been written to:
 /Users/heron/Development/Algoriddim/gnustep-toolchain/gnustep-android/gnustep/libobjc2/build

 /Users/heron/Development/Algoriddim/gnustep-toolchain/gnustep-android/gnustep/libobjc2/build/CMake
 [1/1] Linking CXX executable test_cxx_runtime
 FAILED: test_cxx_runtime
 : &&
 /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwi

Re: Building on android....

[Gregory Casamento]

The ndk and the  Android toolchain file are both current.   I got rid of
the old script and wrote a new one.  I’m using the installation of my sdk
and ndk from an up to date android studio installation.

So it’s not from the past.

On Wed, Feb 13, 2019 at 09:21 David Chisnall 
wrote:

> As I understand it (and this is based on looking a few years ago, so may
> be wrong now) the NDK doesn't provide any C++ environment by default,
> you have to explicitly opt in to one.  It used to provide a choice of
> two, I don't know if it still does.
>
> David
>
> On 13/02/2019 12:41, Gregory Casamento wrote:
> > A little more context...  my build environment is a MacPro 2010 running
> > the latest version of Mojave.  I have downloaded and installed the
> > latest of Android studio and installed the latest SDK and NDK using the
> > menu under tools and the SDK manager.  The version of the NDK I'm using
> > is 19.0.5232133.   I am utterly stumped as to why this is not working.
> > Also, it seems as though Ivan's installation of this is working which
> > seems to indicate that this is a configuration issue.
> >
> > Any input would be appreciated.
> >
> > On Wed, Feb 13, 2019 at 7:09 AM Gregory Casamento
> > mailto:greg.casame...@gmail.com>> wrote:
> >
> > ### Build libobjc2
> >
> > -- The ASM compiler identification is Clang
> >
> > -- Found assembler:
> >
>  
> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
> >
> > -- Check for working C compiler:
> >
>  
> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
> >
> > -- Check for working C compiler:
> >
>  
> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/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/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
> >
> > -- Check for working CXX compiler:
> >
>  
> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
> > -- works
> >
> > -- Detecting CXX compiler ABI info
> >
> > -- Detecting CXX compiler ABI info - done
> >
> > -- Detecting CXX compile features
> >
> > -- Detecting CXX compile features - done
> >
> > -- Testing C++ interop
> >
> > -- Testing C++ standard library
> >
> > -- No useable C++ runtime found
> >
> > -- Looking for pthread.h
> >
> > -- Looking for pthread.h - found
> >
> > -- Looking for pthread_create
> >
> > -- Looking for pthread_create - found
> >
> > -- Found Threads: TRUE
> >
> > -- GNUstep install type set to NONE
> >
> > -- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES
> >
> > -- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES - Success
> >
> > -- Configuring done
> >
> > -- Generating done
> >
> > -- Build files have been written to:
> >
>  
> /Users/heron/Development/Algoriddim/gnustep-toolchain/gnustep-android/gnustep/libobjc2/build
> >
> >
>  
> /Users/heron/Development/Algoriddim/gnustep-toolchain/gnustep-android/gnustep/libobjc2/build/CMake
> >
> > [1/1] Linking CXX executable test_cxx_runtime
> >
> > FAILED: test_cxx_runtime
> >
> > : &&
> >
>  
> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
> > --target=armv7-none-linux-androideabi16
> >
>  
> --gcc-toolchain=/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64--sysroot
> >
>  
> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/sysroot
> > -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables
> > -fstack-protector-strong -no-canonical-prefixes -mfpu=vfpv3-d16
> > -fno-addrsig -mthumb -Wa,--noexecstack -Wformat
> > -Werror=format-security -stdlib=libc++-Wl,--exclude-libs,libgcc.a
> > -Wl,--exclude-libs,libatomic.a -static-libstdc++ -Wl,--build-id
> > -Wl,--warn-shared-textrel-Wl,--exclude-libs,libunwind.a
> > -Wl,--no-undefined -Qunused-arguments -Wl,-z,noexecstack
> > -Wl,-z,relro -Wl,-z,now -Wl,--gc-sections
> > CMakeFiles/test_cxx_runtime.dir/typeinfo_test.cc.o-o
> > test_cxx_runtime-latomic -lm && :
> >
> >
>  CMakeFiles/test_cxx_runtime.dir/typeinfo_test.cc.o:typeinfo_test.cc:vtable
> > for type_info2: error: undefined reference to
> > 'std::type_info::__do_upcast(__cxxabiv1::__class_type_info const*,
> > void**) const'
> >
> > clang++: error: linker command failed with exit code 1 (use -v to
> > see invocation)
> >
> > ninja: build stopped: subcommand failed.
> >
> > ### LIBOBJC2 BUILD FAILED!!!
> >
> >
> > I am running into the above error when trying to build for Android.
> >   

Re: Building on android....

[Jordan Schidlowsky]

I think this line in his output indicates he's building for API 16:

 --target=armv7-none-linux-androideabi16 

> On Feb 13, 2019, at 10:07 AM, Ivan Vučica  wrote:
> 
> Since Greg mentioned me: 
> 
> Instructions/commands I came up with and that I sent over to Gregory should 
> attempt using API level 23. Totally arbitrarily picked. Use of pre-21 API is 
> not happening so not an issue.
> 
> Needless to say, building works for me. I don’t have a self-contained script 
> to share, but it’s super simplistic and what Greg described (incl using GUI 
> to install NDK) is what I did.
> 
> I’m only sure it builds, not that it works, as I am yet to try running the 
> code; I don’t have a build script ready for producing an APK (the old 
> approach from 2013 and 2014 is a mess and needs to be reworked).
> 
> On Wed 13 Feb 2019 at 15:34 Jordan Schidlowsky  > wrote:
> I've got some patches but they are pretty ugly and I want to clean them up 
> properly before submitting...
> 
> 
>> On Feb 13, 2019, at 8:41 AM, Jordan Schidlowsky > > wrote:
>> 
>> An NDK app can chose to bundle in a (c++_shared) library in your app, or you 
>> can link with a static (c++_static) standard library.   This is actually 
>> dependant on what setting you chose for this in your gradle build file, as 
>> gradle will pass that along to cmake which will link it in.  
>> 
>> That cxx runtime test doesn't quite work correctly using an android 
>> toolchain.  But if you want to configure your ndk app using c++_static you 
>> can remove that test section from CMakeLists.txt and add in manually below:
>> 
>> set(CXXRT_IS_STDLIB true)
>> target_link_libraries(objc c++_static stdc++)
>> 
>> I will also note, that I am still thinking about a way to run that test 
>> suite while cross compiling... 
>> 
>> 
>>> On Feb 13, 2019, at 6:41 AM, Gregory Casamento >> > wrote:
>>> 
>>> 
>>> A little more context...  my build environment is a MacPro 2010 running the 
>>> latest version of Mojave.  I have downloaded and installed the latest of 
>>> Android studio and installed the latest SDK and NDK using the menu under 
>>> tools and the SDK manager.  The version of the NDK I'm using is 
>>> 19.0.5232133.   I am utterly stumped as to why this is not working.  Also, 
>>> it seems as though Ivan's installation of this is working which seems to 
>>> indicate that this is a configuration issue.
>>> 
>>> Any input would be appreciated.
>>> 
>>> On Wed, Feb 13, 2019 at 7:09 AM Gregory Casamento >> > wrote:
>>> 
>>> ### Build libobjc2
>>> -- The ASM compiler identification is Clang
>>> -- Found assembler: 
>>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
>>> -- Check for working C compiler: 
>>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
>>> -- Check for working C compiler: 
>>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/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/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
>>> -- Check for working CXX compiler: 
>>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
>>>  -- works
>>> -- Detecting CXX compiler ABI info
>>> -- Detecting CXX compiler ABI info - done
>>> -- Detecting CXX compile features
>>> -- Detecting CXX compile features - done
>>> -- Testing C++ interop
>>> -- Testing C++ standard library
>>> -- No useable C++ runtime found
>>> -- Looking for pthread.h
>>> -- Looking for pthread.h - found
>>> -- Looking for pthread_create
>>> -- Looking for pthread_create - found
>>> -- Found Threads: TRUE  
>>> -- GNUstep install type set to NONE
>>> -- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES
>>> -- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES - Success
>>> -- Configuring done
>>> -- Generating done
>>> -- Build files have been written to: 
>>> /Users/heron/Development/Algoriddim/gnustep-toolchain/gnustep-android/gnustep/libobjc2/build
>>> /Users/heron/Development/Algoriddim/gnustep-toolchain/gnustep-android/gnustep/libobjc2/build/CMake
>>> [1/1] Linking CXX executable test_cxx_runtime
>>> FAILED: test_cxx_runtime 
>>> : && 
>>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
>>>  --target=armv7-none-linux-androideabi16 
>>> --gcc-toolchain=/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64
>>>   --sysroot 
>>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/sysroot
>>>  -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables 
>>> -fstack-protecto

Re: Building on android....

[Ivan Vučica]

Since Greg mentioned me:

Instructions/commands I came up with and that I sent over to Gregory should
attempt using API level 23. Totally arbitrarily picked. Use of pre-21 API
is not happening so not an issue.

Needless to say, building works for me. I don’t have a self-contained
script to share, but it’s super simplistic and what Greg described (incl
using GUI to install NDK) is what I did.

I’m only sure it builds, not that it works, as I am yet to try running the
code; I don’t have a build script ready for producing an APK (the old
approach from 2013 and 2014 is a mess and needs to be reworked).

On Wed 13 Feb 2019 at 15:34 Jordan Schidlowsky 
wrote:

> I've got some patches but they are pretty ugly and I want to clean them up
> properly before submitting...
>
> On Feb 13, 2019, at 8:41 AM, Jordan Schidlowsky 
> wrote:
>
> An NDK app can chose to bundle in a (c++_shared) library in your app, or
> you can link with a static (c++_static) standard library.   This is
> actually dependant on what setting you chose for this in your gradle build
> file, as gradle will pass that along to cmake which will link it in.
>
> That cxx runtime test doesn't quite work correctly using an android
> toolchain.  But if you want to configure your ndk app using c++_static you
> can remove that test section from CMakeLists.txt and add in manually below:
>
> set(CXXRT_IS_STDLIB true)
> target_link_libraries(objc c++_static stdc++)
>
> I will also note, that I am still thinking about a way to run that test
> suite while cross compiling...
>
>
> On Feb 13, 2019, at 6:41 AM, Gregory Casamento 
> wrote:
>
> A little more context...  my build environment is a MacPro 2010 running
> the latest version of Mojave.  I have downloaded and installed the latest
> of Android studio and installed the latest SDK and NDK using the menu under
> tools and the SDK manager.  The version of the NDK I'm using is 19.0.5232133.
>  I am utterly stumped as to why this is not working.  Also, it seems as
> though Ivan's installation of this is working which seems to indicate that
> this is a configuration issue.
>
> Any input would be appreciated.
>
> On Wed, Feb 13, 2019 at 7:09 AM Gregory Casamento <
> greg.casame...@gmail.com> wrote:
>
>> ### Build libobjc2
>> -- The ASM compiler identification is Clang
>> -- Found assembler:
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
>> -- Check for working C compiler:
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
>> -- Check for working C compiler:
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/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/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
>> -- Check for working CXX compiler:
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
>> -- works
>> -- Detecting CXX compiler ABI info
>> -- Detecting CXX compiler ABI info - done
>> -- Detecting CXX compile features
>> -- Detecting CXX compile features - done
>> -- Testing C++ interop
>> -- Testing C++ standard library
>> -- No useable C++ runtime found
>> -- Looking for pthread.h
>> -- Looking for pthread.h - found
>> -- Looking for pthread_create
>> -- Looking for pthread_create - found
>> -- Found Threads: TRUE
>> -- GNUstep install type set to NONE
>> -- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES
>> -- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES - Success
>> -- Configuring done
>> -- Generating done
>> -- Build files have been written to:
>> /Users/heron/Development/Algoriddim/gnustep-toolchain/gnustep-android/gnustep/libobjc2/build
>>
>> /Users/heron/Development/Algoriddim/gnustep-toolchain/gnustep-android/gnustep/libobjc2/build/CMake
>> [1/1] Linking CXX executable test_cxx_runtime
>> FAILED: test_cxx_runtime
>> : &&
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
>> --target=armv7-none-linux-androideabi16
>> --gcc-toolchain=/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64
>>   --sysroot
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/sysroot
>> -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables
>> -fstack-protector-strong -no-canonical-prefixes -mfpu=vfpv3-d16
>> -fno-addrsig -mthumb -Wa,--noexecstack -Wformat -Werror=format-security
>> -stdlib=libc++  -Wl,--exclude-libs,libgcc.a
>> -Wl,--exclude-libs,libatomic.a -static-libstdc++ -Wl,--build-id
>> -Wl,--warn-shared-textrel  -Wl,--exclude-libs,libunwind.a
>> -Wl,--no-undefined -Qunused-arguments -Wl,-z,noexecstack -Wl,-z,relro
>> -Wl,-z,now -Wl,--gc-sections
>> CMakeFiles/test_cxx_runtime.dir/typeinfo_test.cc.o 

Re: Building on android....

[Jordan Schidlowsky]

I've got some patches but they are pretty ugly and I want to clean them up 
properly before submitting...

> On Feb 13, 2019, at 8:41 AM, Jordan Schidlowsky  wrote:
> 
> An NDK app can chose to bundle in a (c++_shared) library in your app, or you 
> can link with a static (c++_static) standard library.   This is actually 
> dependant on what setting you chose for this in your gradle build file, as 
> gradle will pass that along to cmake which will link it in.  
> 
> That cxx runtime test doesn't quite work correctly using an android 
> toolchain.  But if you want to configure your ndk app using c++_static you 
> can remove that test section from CMakeLists.txt and add in manually below:
> 
> set(CXXRT_IS_STDLIB true)
> target_link_libraries(objc c++_static stdc++)
> 
> I will also note, that I am still thinking about a way to run that test suite 
> while cross compiling... 
> 
> 
>> On Feb 13, 2019, at 6:41 AM, Gregory Casamento > > wrote:
>> 
>> 
>> A little more context...  my build environment is a MacPro 2010 running the 
>> latest version of Mojave.  I have downloaded and installed the latest of 
>> Android studio and installed the latest SDK and NDK using the menu under 
>> tools and the SDK manager.  The version of the NDK I'm using is 
>> 19.0.5232133.   I am utterly stumped as to why this is not working.  Also, 
>> it seems as though Ivan's installation of this is working which seems to 
>> indicate that this is a configuration issue.
>> 
>> Any input would be appreciated.
>> 
>> On Wed, Feb 13, 2019 at 7:09 AM Gregory Casamento > > wrote:
>> 
>> ### Build libobjc2
>> -- The ASM compiler identification is Clang
>> -- Found assembler: 
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
>> -- Check for working C compiler: 
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
>> -- Check for working C compiler: 
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/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/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
>> -- Check for working CXX compiler: 
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
>>  -- works
>> -- Detecting CXX compiler ABI info
>> -- Detecting CXX compiler ABI info - done
>> -- Detecting CXX compile features
>> -- Detecting CXX compile features - done
>> -- Testing C++ interop
>> -- Testing C++ standard library
>> -- No useable C++ runtime found
>> -- Looking for pthread.h
>> -- Looking for pthread.h - found
>> -- Looking for pthread_create
>> -- Looking for pthread_create - found
>> -- Found Threads: TRUE  
>> -- GNUstep install type set to NONE
>> -- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES
>> -- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES - Success
>> -- Configuring done
>> -- Generating done
>> -- Build files have been written to: 
>> /Users/heron/Development/Algoriddim/gnustep-toolchain/gnustep-android/gnustep/libobjc2/build
>> /Users/heron/Development/Algoriddim/gnustep-toolchain/gnustep-android/gnustep/libobjc2/build/CMake
>> [1/1] Linking CXX executable test_cxx_runtime
>> FAILED: test_cxx_runtime 
>> : && 
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
>>  --target=armv7-none-linux-androideabi16 
>> --gcc-toolchain=/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64
>>   --sysroot 
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/sysroot
>>  -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables 
>> -fstack-protector-strong -no-canonical-prefixes -mfpu=vfpv3-d16 -fno-addrsig 
>> -mthumb -Wa,--noexecstack -Wformat -Werror=format-security -stdlib=libc++  
>> -Wl,--exclude-libs,libgcc.a -Wl,--exclude-libs,libatomic.a -static-libstdc++ 
>> -Wl,--build-id -Wl,--warn-shared-textrel  -Wl,--exclude-libs,libunwind.a 
>> -Wl,--no-undefined -Qunused-arguments -Wl,-z,noexecstack -Wl,-z,relro 
>> -Wl,-z,now -Wl,--gc-sections 
>> CMakeFiles/test_cxx_runtime.dir/typeinfo_test.cc.o  -o test_cxx_runtime  
>> -latomic -lm && :
>> CMakeFiles/test_cxx_runtime.dir/typeinfo_test.cc.o:typeinfo_test.cc 
>> :vtable for type_info2: error: undefined reference 
>> to 'std::type_info::__do_upcast(__cxxabiv1::__class_type_info const*, 
>> void**) const'
>> clang++: error: linker command failed with exit code 1 (use -v to see 
>> invocation)
>> ninja: build stopped: subcommand failed.
>> ### LIBOBJC2 BUILD FAILED!!!
>> 
>> I am running into the above error when trying to build for Android.  I have 
>> the latest ndk and sdk

Re: Building on android....

[Jordan Schidlowsky]

I also wouldn't try building for anything below android 21, bionic has a bunch 
of stuff thats missing in libc and libc++ and you have to also link in 
libandroid_support for those api levels.  From the NDK changelog:


libandroid_support is no longer used when your NDK API level is greater than or 
equal to 21 (Lollipop). Build system maintainers: be sure to update your build 
systems to account for this.
The platform static libraries (libc.a, libm.a, etc.) have been updated.
All NDK platforms now contain a modern version of these static libraries. 
Previously they were all Gingerbread (perhaps even older) or Lollipop.
Prior NDKs could not use the static libraries with a modern NDK API level 
because of symbol collisions between libc.a and libandroid_support. This has 
been solved by removing libandroid_support for modern API levels. A side effect 
of this is that you must now target at least android-21 to use the static 
libraries, but these binaries will still work on older devices.


> On Feb 13, 2019, at 8:41 AM, Jordan Schidlowsky  wrote:
> 
> An NDK app can chose to bundle in a (c++_shared) library in your app, or you 
> can link with a static (c++_static) standard library.   This is actually 
> dependant on what setting you chose for this in your gradle build file, as 
> gradle will pass that along to cmake which will link it in.  
> 
> That cxx runtime test doesn't quite work correctly using an android 
> toolchain.  But if you want to configure your ndk app using c++_static you 
> can remove that test section from CMakeLists.txt and add in manually below:
> 
> set(CXXRT_IS_STDLIB true)
> target_link_libraries(objc c++_static stdc++)
> 
> I will also note, that I am still thinking about a way to run that test suite 
> while cross compiling... 
> 
> 
>> On Feb 13, 2019, at 6:41 AM, Gregory Casamento > > wrote:
>> 
>> 
>> A little more context...  my build environment is a MacPro 2010 running the 
>> latest version of Mojave.  I have downloaded and installed the latest of 
>> Android studio and installed the latest SDK and NDK using the menu under 
>> tools and the SDK manager.  The version of the NDK I'm using is 
>> 19.0.5232133.   I am utterly stumped as to why this is not working.  Also, 
>> it seems as though Ivan's installation of this is working which seems to 
>> indicate that this is a configuration issue.
>> 
>> Any input would be appreciated.
>> 
>> On Wed, Feb 13, 2019 at 7:09 AM Gregory Casamento > > wrote:
>> 
>> ### Build libobjc2
>> -- The ASM compiler identification is Clang
>> -- Found assembler: 
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
>> -- Check for working C compiler: 
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
>> -- Check for working C compiler: 
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/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/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
>> -- Check for working CXX compiler: 
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
>>  -- works
>> -- Detecting CXX compiler ABI info
>> -- Detecting CXX compiler ABI info - done
>> -- Detecting CXX compile features
>> -- Detecting CXX compile features - done
>> -- Testing C++ interop
>> -- Testing C++ standard library
>> -- No useable C++ runtime found
>> -- Looking for pthread.h
>> -- Looking for pthread.h - found
>> -- Looking for pthread_create
>> -- Looking for pthread_create - found
>> -- Found Threads: TRUE  
>> -- GNUstep install type set to NONE
>> -- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES
>> -- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES - Success
>> -- Configuring done
>> -- Generating done
>> -- Build files have been written to: 
>> /Users/heron/Development/Algoriddim/gnustep-toolchain/gnustep-android/gnustep/libobjc2/build
>> /Users/heron/Development/Algoriddim/gnustep-toolchain/gnustep-android/gnustep/libobjc2/build/CMake
>> [1/1] Linking CXX executable test_cxx_runtime
>> FAILED: test_cxx_runtime 
>> : && 
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
>>  --target=armv7-none-linux-androideabi16 
>> --gcc-toolchain=/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64
>>   --sysroot 
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/sysroot
>>  -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables 
>> -fstack-protector-strong -no-canonical-prefixes -mfpu=vfpv3-d16 -fno-addrsig 
>> -mthumb -Wa,--noexecstack -Wformat -Werror=format-security -st

Re: Building on android....

[David Chisnall]

On 13/02/2019 14:41, Jordan Schidlowsky wrote:
An NDK app can chose to bundle in a (c++_shared) library in your app, or 
you can link with a static (c++_static) standard library.   This is 
actually dependant on what setting you chose for this in your gradle 
build file, as gradle will pass that along to cmake which will link it in.


That cxx runtime test doesn't quite work correctly using an android 
toolchain.  But if you want to configure your ndk app using c++_static 
you can remove that test section from CMakeLists.txt and add in manually 
below:


set(CXXRT_IS_STDLIB true)
target_link_libraries(objc c++_static stdc++)

I will also note, that I am still thinking about a way to run that test 
suite while cross compiling...


Patches to the cmake very welcome!  I believe that the test really just 
needs to check if the program links correctly, not if it works.  I'm 
only running it because that works on platforms where programs will 
successfully link against DSOs that don't provide all of the symbols 
that they'll need.


David

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Building on android....

[Jordan Schidlowsky]

An NDK app can chose to bundle in a (c++_shared) library in your app, or you 
can link with a static (c++_static) standard library.   This is actually 
dependant on what setting you chose for this in your gradle build file, as 
gradle will pass that along to cmake which will link it in.  

That cxx runtime test doesn't quite work correctly using an android toolchain.  
But if you want to configure your ndk app using c++_static you can remove that 
test section from CMakeLists.txt and add in manually below:

set(CXXRT_IS_STDLIB true)
target_link_libraries(objc c++_static stdc++)

I will also note, that I am still thinking about a way to run that test suite 
while cross compiling... 


> On Feb 13, 2019, at 6:41 AM, Gregory Casamento  
> wrote:
> 
> 
> A little more context...  my build environment is a MacPro 2010 running the 
> latest version of Mojave.  I have downloaded and installed the latest of 
> Android studio and installed the latest SDK and NDK using the menu under 
> tools and the SDK manager.  The version of the NDK I'm using is 19.0.5232133. 
>   I am utterly stumped as to why this is not working.  Also, it seems as 
> though Ivan's installation of this is working which seems to indicate that 
> this is a configuration issue.
> 
> Any input would be appreciated.
> 
> On Wed, Feb 13, 2019 at 7:09 AM Gregory Casamento  > wrote:
> 
> ### Build libobjc2
> -- The ASM compiler identification is Clang
> -- Found assembler: 
> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
> -- Check for working C compiler: 
> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
> -- Check for working C compiler: 
> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/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/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
> -- Check for working CXX compiler: 
> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
>  -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Testing C++ interop
> -- Testing C++ standard library
> -- No useable C++ runtime found
> -- Looking for pthread.h
> -- Looking for pthread.h - found
> -- Looking for pthread_create
> -- Looking for pthread_create - found
> -- Found Threads: TRUE  
> -- GNUstep install type set to NONE
> -- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES
> -- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES - Success
> -- Configuring done
> -- Generating done
> -- Build files have been written to: 
> /Users/heron/Development/Algoriddim/gnustep-toolchain/gnustep-android/gnustep/libobjc2/build
> /Users/heron/Development/Algoriddim/gnustep-toolchain/gnustep-android/gnustep/libobjc2/build/CMake
> [1/1] Linking CXX executable test_cxx_runtime
> FAILED: test_cxx_runtime 
> : && 
> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
>  --target=armv7-none-linux-androideabi16 
> --gcc-toolchain=/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64
>   --sysroot 
> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/sysroot
>  -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables 
> -fstack-protector-strong -no-canonical-prefixes -mfpu=vfpv3-d16 -fno-addrsig 
> -mthumb -Wa,--noexecstack -Wformat -Werror=format-security -stdlib=libc++  
> -Wl,--exclude-libs,libgcc.a -Wl,--exclude-libs,libatomic.a -static-libstdc++ 
> -Wl,--build-id -Wl,--warn-shared-textrel  -Wl,--exclude-libs,libunwind.a 
> -Wl,--no-undefined -Qunused-arguments -Wl,-z,noexecstack -Wl,-z,relro 
> -Wl,-z,now -Wl,--gc-sections 
> CMakeFiles/test_cxx_runtime.dir/typeinfo_test.cc.o  -o test_cxx_runtime  
> -latomic -lm && :
> CMakeFiles/test_cxx_runtime.dir/typeinfo_test.cc.o:typeinfo_test.cc:vtable 
> for type_info2: error: undefined reference to 
> 'std::type_info::__do_upcast(__cxxabiv1::__class_type_info const*, void**) 
> const'
> clang++: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> ninja: build stopped: subcommand failed.
> ### LIBOBJC2 BUILD FAILED!!!
> 
> I am running into the above error when trying to build for Android.  I have 
> the latest ndk and sdk installed with Android studio.  Does anyone have any 
> idea offhand why C++ isn't finding it's runtime?   I will attach the build 
> script I am using to generate the ninja script
> 
> GC
> 
> -- 
> Gregory Casamento
> GNUstep Lead Developer / OLC, Principal Consultant
> http://www.gnustep.org 
> 

Re: Building on android....

[David Chisnall]

As I understand it (and this is based on looking a few years ago, so may 
be wrong now) the NDK doesn't provide any C++ environment by default, 
you have to explicitly opt in to one.  It used to provide a choice of 
two, I don't know if it still does.


David

On 13/02/2019 12:41, Gregory Casamento wrote:
A little more context...  my build environment is a MacPro 2010 running 
the latest version of Mojave.  I have downloaded and installed the 
latest of Android studio and installed the latest SDK and NDK using the 
menu under tools and the SDK manager.  The version of the NDK I'm using 
is 19.0.5232133.   I am utterly stumped as to why this is not working.  
Also, it seems as though Ivan's installation of this is working which 
seems to indicate that this is a configuration issue.


Any input would be appreciated.

On Wed, Feb 13, 2019 at 7:09 AM Gregory Casamento 
mailto:greg.casame...@gmail.com>> wrote:


### Build libobjc2

-- The ASM compiler identification is Clang

-- Found assembler:

/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang

-- Check for working C compiler:

/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang

-- Check for working C compiler:

/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/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/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++

-- Check for working CXX compiler:

/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
-- works

-- Detecting CXX compiler ABI info

-- Detecting CXX compiler ABI info - done

-- Detecting CXX compile features

-- Detecting CXX compile features - done

-- Testing C++ interop

-- Testing C++ standard library

-- No useable C++ runtime found

-- Looking for pthread.h

-- Looking for pthread.h - found

-- Looking for pthread_create

-- Looking for pthread_create - found

-- Found Threads: TRUE

-- GNUstep install type set to NONE

-- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES

-- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES - Success

-- Configuring done

-- Generating done

-- Build files have been written to:

/Users/heron/Development/Algoriddim/gnustep-toolchain/gnustep-android/gnustep/libobjc2/build


/Users/heron/Development/Algoriddim/gnustep-toolchain/gnustep-android/gnustep/libobjc2/build/CMake

[1/1] Linking CXX executable test_cxx_runtime

FAILED: test_cxx_runtime

: &&

/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
--target=armv7-none-linux-androideabi16

--gcc-toolchain=/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64--sysroot

/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/sysroot
-g -DANDROID -fdata-sections -ffunction-sections -funwind-tables
-fstack-protector-strong -no-canonical-prefixes -mfpu=vfpv3-d16
-fno-addrsig -mthumb -Wa,--noexecstack -Wformat
-Werror=format-security -stdlib=libc++-Wl,--exclude-libs,libgcc.a
-Wl,--exclude-libs,libatomic.a -static-libstdc++ -Wl,--build-id
-Wl,--warn-shared-textrel-Wl,--exclude-libs,libunwind.a
-Wl,--no-undefined -Qunused-arguments -Wl,-z,noexecstack
-Wl,-z,relro -Wl,-z,now -Wl,--gc-sections
CMakeFiles/test_cxx_runtime.dir/typeinfo_test.cc.o-o
test_cxx_runtime-latomic -lm && :

CMakeFiles/test_cxx_runtime.dir/typeinfo_test.cc.o:typeinfo_test.cc:vtable
for type_info2: error: undefined reference to
'std::type_info::__do_upcast(__cxxabiv1::__class_type_info const*,
void**) const'

clang++: error: linker command failed with exit code 1 (use -v to
see invocation)

ninja: build stopped: subcommand failed.

### LIBOBJC2 BUILD FAILED!!!


I am running into the above error when trying to build for Android. 
I have the latest ndk and sdk installed with Android studio.  Does

anyone have any idea offhand why C++ isn't finding it's runtime?   I
will attach the build script I am using to generate the ninja script

GC

-- 
Gregory Casamento

GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org


- http://heronsperch.blogspot.com


http://ind.ie/

Re: Building on android....

[Gregory Casamento]

A little more context...  my build environment is a MacPro 2010 running the
latest version of Mojave.  I have downloaded and installed the latest of
Android studio and installed the latest SDK and NDK using the menu under
tools and the SDK manager.  The version of the NDK I'm using is 19.0.5232133.
 I am utterly stumped as to why this is not working.  Also, it seems as
though Ivan's installation of this is working which seems to indicate that
this is a configuration issue.

Any input would be appreciated.

On Wed, Feb 13, 2019 at 7:09 AM Gregory Casamento 
wrote:

> ### Build libobjc2
>
> -- The ASM compiler identification is Clang
>
> -- Found assembler:
> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
>
> -- Check for working C compiler:
> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
>
> -- Check for working C compiler:
> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/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/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
>
> -- Check for working CXX compiler:
> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
> -- works
>
> -- Detecting CXX compiler ABI info
>
> -- Detecting CXX compiler ABI info - done
>
> -- Detecting CXX compile features
>
> -- Detecting CXX compile features - done
>
> -- Testing C++ interop
>
> -- Testing C++ standard library
>
> -- No useable C++ runtime found
>
> -- Looking for pthread.h
>
> -- Looking for pthread.h - found
>
> -- Looking for pthread_create
>
> -- Looking for pthread_create - found
>
> -- Found Threads: TRUE
>
> -- GNUstep install type set to NONE
>
> -- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES
>
> -- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES - Success
>
> -- Configuring done
>
> -- Generating done
>
> -- Build files have been written to:
> /Users/heron/Development/Algoriddim/gnustep-toolchain/gnustep-android/gnustep/libobjc2/build
>
>
> /Users/heron/Development/Algoriddim/gnustep-toolchain/gnustep-android/gnustep/libobjc2/build/CMake
>
> [1/1] Linking CXX executable test_cxx_runtime
>
> FAILED: test_cxx_runtime
>
> : &&
> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
> --target=armv7-none-linux-androideabi16
> --gcc-toolchain=/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64
> --sysroot
> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/sysroot
> -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables
> -fstack-protector-strong -no-canonical-prefixes -mfpu=vfpv3-d16
> -fno-addrsig -mthumb -Wa,--noexecstack -Wformat -Werror=format-security
> -stdlib=libc++  -Wl,--exclude-libs,libgcc.a
> -Wl,--exclude-libs,libatomic.a -static-libstdc++ -Wl,--build-id
> -Wl,--warn-shared-textrel  -Wl,--exclude-libs,libunwind.a
> -Wl,--no-undefined -Qunused-arguments -Wl,-z,noexecstack -Wl,-z,relro
> -Wl,-z,now -Wl,--gc-sections
> CMakeFiles/test_cxx_runtime.dir/typeinfo_test.cc.o  -o test_cxx_runtime  
> -latomic
> -lm && :
>
> CMakeFiles/test_cxx_runtime.dir/typeinfo_test.cc.o:typeinfo_test.cc:vtable
> for type_info2: error: undefined reference to
> 'std::type_info::__do_upcast(__cxxabiv1::__class_type_info const*, void**)
> const'
>
> clang++: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
> ninja: build stopped: subcommand failed.
>
> ### LIBOBJC2 BUILD FAILED!!!
>
> I am running into the above error when trying to build for Android.  I
> have the latest ndk and sdk installed with Android studio.  Does anyone
> have any idea offhand why C++ isn't finding it's runtime?   I will attach
> the build script I am using to generate the ninja script
>
> GC
>
> --
> Gregory Casamento
> GNUstep Lead Developer / OLC, Principal Consultant
> http://www.gnustep.org
> 
> - http://heronsperch.blogspot.com
> 
> http://ind.ie/phoenix/
> 
>


-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org

- http://heronsperch.blogspot.com

Building on android....

[Gregory Casamento]

### Build libobjc2

-- The ASM compiler identification is Clang

-- Found assembler:
/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang

-- Check for working C compiler:
/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang

-- Check for working C compiler:
/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/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/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++

-- Check for working CXX compiler:
/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
-- works

-- Detecting CXX compiler ABI info

-- Detecting CXX compiler ABI info - done

-- Detecting CXX compile features

-- Detecting CXX compile features - done

-- Testing C++ interop

-- Testing C++ standard library

-- No useable C++ runtime found

-- Looking for pthread.h

-- Looking for pthread.h - found

-- Looking for pthread_create

-- Looking for pthread_create - found

-- Found Threads: TRUE

-- GNUstep install type set to NONE

-- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES

-- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES - Success

-- Configuring done

-- Generating done

-- Build files have been written to:
/Users/heron/Development/Algoriddim/gnustep-toolchain/gnustep-android/gnustep/libobjc2/build

/Users/heron/Development/Algoriddim/gnustep-toolchain/gnustep-android/gnustep/libobjc2/build/CMake

[1/1] Linking CXX executable test_cxx_runtime

FAILED: test_cxx_runtime

: &&
/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
--target=armv7-none-linux-androideabi16
--gcc-toolchain=/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64
--sysroot
/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/sysroot
-g -DANDROID -fdata-sections -ffunction-sections -funwind-tables
-fstack-protector-strong -no-canonical-prefixes -mfpu=vfpv3-d16
-fno-addrsig -mthumb -Wa,--noexecstack -Wformat -Werror=format-security
-stdlib=libc++  -Wl,--exclude-libs,libgcc.a -Wl,--exclude-libs,libatomic.a
-static-libstdc++ -Wl,--build-id -Wl,--warn-shared-textrel
-Wl,--exclude-libs,libunwind.a
-Wl,--no-undefined -Qunused-arguments -Wl,-z,noexecstack -Wl,-z,relro
-Wl,-z,now -Wl,--gc-sections
CMakeFiles/test_cxx_runtime.dir/typeinfo_test.cc.o  -o
test_cxx_runtime  -latomic
-lm && :

CMakeFiles/test_cxx_runtime.dir/typeinfo_test.cc.o:typeinfo_test.cc:vtable
for type_info2: error: undefined reference to
'std::type_info::__do_upcast(__cxxabiv1::__class_type_info const*, void**)
const'

clang++: error: linker command failed with exit code 1 (use -v to see
invocation)

ninja: build stopped: subcommand failed.

### LIBOBJC2 BUILD FAILED!!!

I am running into the above error when trying to build for Android.  I have
the latest ndk and sdk installed with Android studio.  Does anyone have any
idea offhand why C++ isn't finding it's runtime?   I will attach the build
script I am using to generate the ninja script

GC

-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org

- http://heronsperch.blogspot.com

http://ind.ie/phoenix/

# Script by Gregory Casamento & Ivan Vucica
#
# from android documentation:
# http://web.archive.org/web/20190210195102/
# https://developer.android.com/ndk/guides/cmake

export ANDROID_HOME="${HOME}"/Library/Android/sdk
export ANDROID_NDK_HOME=${ANDROID_HOME}/ndk-bundle
export ANDROID_CMAKE_ROOT=${ANDROID_HOME}/cmake/3.10.2.4988404
export CMAKE_TOOLCHAIN_FILE=${ANDROID_NDK_HOME}/build/cmake/android.toolchain.cmake
export NINJA=${ANDROID_CMAKE_ROOT}/bin/ninja
export ROOT_DIR=`pwd`
export GSROOT=${ROOT_DIR}/gnustep
export INSTALL_PREFIX=${ROOT_DIR}/android-gnustep
export ANDROID_GNUSTEP_INSTALL_ROOT="${GSROOT}"/"${INSTALL_PREFIX}"

cd $ROOT_DIR

echo "### Setup build for libobjc2"
rm -rf "${GSROOT}"
mkdir -p "${GSROOT}"
  
if [[ ! -e "${GSROOT}"/libobjc2 ]] ; then
  cd "${GSROOT}"
  git clone https://github.com/gnustep/libobjc2
  mkdir -p "${GSROOT}"/libobjc2/build
fi

echo "### Build libobjc2"
cd "${GSROOT}"
${ANDROID_CMAKE_ROOT}/bin/cmake \
  -H"${GSROOT}"/libobjc2 \
  -B"${GSROOT}"/libobjc2/build \
  -G"Ninja" \
  -DANDROID_ABI=armeabi-v7a \
  -DANDRO