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