Re: Objective-C code running on Android

[David Chisnall]

On 25 Jun 2011, at 00:45, Ivan Vučica wrote:

> Regarding getting GUI to work, that would be something amazing. It would 
> perhaps be even more interesting to get Java-ObjC bridge to work -- that 
> would allow getting native GUI to work. AppKit user interfaces are pretty 
> much designed for use on desktops, and one would need to redesign the GUI 
> anyway to run it on mobile. (Using an NSPanel, for example, would be quite a 
> strange experience on a mobile device.)
> 
> It looks like there will be more work involved in getting clang to work. I 
> just tried using Apple's clang to compile code for Android. Instead of using 
> the custom compiler,  I've tried to use clang with specified -arch armv6 and 
> with added appropriate include paths.
> 
> #OBJC=$(NDKOBJC)/usr/local/android/bin/arm-eabi-gcc
> OBJC=clang -I `dirname 
> \`$(NDK)/toolchains/arm-linux-androideabi-4.4.3/prebuilt/darwin-x86/bin/arm-linux-androideabi-gcc
>  -print-libgcc-file-name\``/include -I `dirname 
> \`$(NDKOBJC)/usr/local/android/bin/arm-eabi-gcc 
> -print-libgcc-file-name\``/include -arch armv6

It's slightly more complicated.  You also have to tell clang which as and ld to 
use.  I think you should be able to do this with -triple rather than -arch 
(which will still be trying to produce Darwin Mach-O binaries, just for ARM).  
It also needs to know to produce Linux / ELF binaries.

> 
> It is already quite promising; I did not really connect the dots enough to 
> expect to find an ARM backend.
> 
> However, headers from the same GCC version conflict among themselves:
> 
> In file included from test.m:1:
> In file included from 
> /Applications/android-sdk-mac_x86/ndk-objc/usr/local/android/bin/../lib/gcc/arm-eabi/4.2.1/include/objc/Object.h:31:
> In file included from 
> /Applications/android-sdk-mac_x86/ndk-objc/usr/local/android/bin/../lib/gcc/arm-eabi/4.2.1/include/objc/typedstream.h:33:
> In file included from 
> /Applications/android-sdk-mac_x86/android-ndk-r5c/platforms/android-5/arch-arm//usr/include/stdio.h:42:
> In file included from 
> /Applications/android-sdk-mac_x86/android-ndk-r5c/platforms/android-5/arch-arm//usr/include/sys/_types.h:40:
> /Applications/android-sdk-mac_x86/android-ndk-r5c/platforms/android-5/arch-arm//usr/include/machine/_types.h:46:24:
>  error:
>      typedef redefinition with different types ('long' vs 'int')
> typedef long           ptrdiff_t;
>                       ^
> In file included from test.m:1:
> In file included from 
> /Applications/android-sdk-mac_x86/ndk-objc/usr/local/android/bin/../lib/gcc/arm-eabi/4.2.1/include/objc/Object.h:30:
> In file included from 
> /Applications/android-sdk-mac_x86/ndk-objc/usr/local/android/bin/../lib/gcc/arm-eabi/4.2.1/include/objc/objc.h:34:
> /Applications/android-sdk-mac_x86/android-ndk-r5c/toolchains/arm-linux-androideabi-4.4.3/prebuilt/darwin-x86/bin/../lib/gcc/arm-linux-androideabi/4.4.3/include/stddef.h:149:26:
>  note:
>      previous definition is here
> typedef __PTRDIFF_TYPE__ ptrdiff_t;
>                         ^
> 
> It's the same if I specify only the custom compiler (the 4.2.1), and if I 
> specify the Android compiler (4.4.3).
> 
> Apparently GCC tolerates int being used as equal to long, while clang does 
> not. I would fix this in headers, but I suspect there might be more such 
> differences.
> 
> Any tips on getting clang to be more tolerant?

I don't think so.  You can try -std=gnu99, but this redefinition of the typedef 
is not allowed in standard C (int and long are distinct types, even if they 
have the same type), so if gcc accepts it then it's a GCC bug.

David

-- Sent from my brain