[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Objective-C code running on Android

From: Ivan Vučica
Subject: Re: Objective-C code running on Android
Date: Sat, 25 Jun 2011 12:12:06 +0200

Regarding as and ld, I had to handle this for the custom gcc already; it does not even come to the assembly phase :)

Regarding increasing tolerance, I agree gcc accepting this would be gcc bug. Maybe gcc defines additional preprocessor macros that make the headers define ptrdiff only once?

I'll try investigating some more.


Ivan Vučica
via phone

On 25. lip. 2011., at 11:00, David Chisnall <theraven@sucs.org> wrote:

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=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.


-- Sent from my brain

reply via email to

[Prev in Thread] Current Thread [Next in Thread]