Re: Objective-C code running on Android

[Ivan Vučica]

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 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?

Regards,

Ivan Vučica
via phone

On 24. lip. 2011., at 23:24, David Chisnall <theraven@sucs.org> wrote:

> On 24 Jun 2011, at 21:58, Ivan Vučica wrote:
>
> > On Fri, Jun 24, 2011 at 22:55, Pirmin Braun <pb@seat-1.com> wrote:
> > Am Fri, 24 Jun 2011 22:03:31 +0200
> > schrieb Ivan Vučica <ivucica@gmail.com> :
> >
> > > Is there any interest in getting at least GNUstep's Foundation to  
> > > run on
> > > Android?
> >
> > yes.
> >
> > I am almost certain that I will NOT be able to successfully do  
> > this, which is why I have posted on this list. :-)
>
> I'm interested.  The clang that Apple ships can target ARM and the  
> GNU runtimes, so you should be able to target android without a  
> custom compiler, although you will need a copy of Android binutils  
> for linking, along with the Android headers.
>
> With the latest NDK, there is even the possibility of running -gui.   
> There's a Skia back end for Cairo, so it should be possible to port  
> the drawing part with minimal effort, although the event handling  
> and window management code will need writing.
>
> David
>
> --
> This email complies with ISO 3103