www.digitalmars.com         C & C++   DMDScript  

D.gnu - how to help with android

reply maarten van damme <maartenvd1994 gmail.com> writes:
Hello, I would really want to use D on android. I've seen
https://bitbucket.org/goshawk/gdc/wiki/GDC%20on%20Android and judging
by the TODO's it's not really usable right now.

Is there a way I can contribute/help any way? I don't have any
knowledge about druntime but quite some spare time right now.

I've also read that android never claims to be possix compliant yet
this site disagree's:
http://developer.android.com/guide/appendix/glossary.html
Jul 24 2012
parent reply Johannes Pfau <nospam example.com> writes:
Am Tue, 24 Jul 2012 20:12:33 +0200
schrieb maarten van damme <maartenvd1994 gmail.com>:

 Hello, I would really want to use D on android. I've seen
 https://bitbucket.org/goshawk/gdc/wiki/GDC%20on%20Android and judging
 by the TODO's it's not really usable right now.
 
 Is there a way I can contribute/help any way? I don't have any
 knowledge about druntime but quite some spare time right now.
Yeah I should continue the Android port at some time. I have some local changes to the android build system to easily build d apps, but there are still some big roadblocks for Android support: * Android doesn't have native TLS. D needs native TLS (In this case 'native' means not 'posix tls'. 'posix tls' means "pthread_key_create", 'native' means "__thread"). We can use GCCs emulated TLS, but currently emulated TLS doesn't interface to the GC correctly (the GC doesn't scan TLS memory right now) * Android doesn't officially support native executables. I'm not sure where this statement is hidden, but it is an official statement. For example their linker is broken when accessing a global variable from a native application in a specific way. Just to emphasize how bad this really is: If you want to access stdout (the C global variable) which is used in writeln for example, you have to use hacks and dladdr to load the address of stdout. You can't simply declare it as external. So you can't actually write a hello world native exacutalbe with D for Android. The Android devs don't care about those issues, as native executables are not supported anyway. But you wouldn't want to use native executables anyway. For example native executables have no possibility to draw a GUI. There's just no way to access the required window handle from a native executable. Instead the supported way to write a "Native Application" is to write a Java stub which loads a shared .so library and calls functions of that library. With recent versions of Android/NDK you don't have to write that stub yourself, it's included in the "NativeApplication" but it still works the same way: Java code loads a .so library. Which leads to the next problem: * Shared library support in D is probably not good enough to do that right now. We need: * Phobos as a shared library * Druntime as a shared library (it actually compiles as a shared library on ARM/Android as the asm code preventing that on x86 is not used, but I don't know whether it is really working) * Loading a shared D library should automatically load druntime and enable the GC (could maybe be done manually) * I'm not sure if this is necessary for Android, but at some point it should be possible to load two D .so libraries into a C application. Those libraries should use the same GC, runtime, etc... Doesn't seem like an easy fix though. Those are the known compiler issues. At least the TLS and the shared library issue has to be fixed, unless that's done there's no need to look at the library side. For the libraries: * The unittest for phobos and druntime must be run and fixed. (This is not as easy as it sounds: We have to run the unittests with the cross compiler. And we can't really run unittests as native executables because of the issues described above. We'd have to build unittests as a .so and run them from a Java APP / "Native Application") * Some modules in phobos need porting. For example std.stdio uses fwide which isn't available on Android, so we have to add special cases for Android. There are probably more similar problems, as Android doesn't implement all Posix APIs. * When all that stuff is working, we can actually start interfacing to Android APIs. We'd need JNI bindings, bindings to the Android API's and at some point higher level wrappers would be nice.
 
 I've also read that android never claims to be possix compliant yet
 this site disagree's:
 http://developer.android.com/guide/appendix/glossary.html
You mean the "Dalvik" part? It only needs some Posix APIs, not all. Bionic/Android has (mostly) Posix compliant threading. Other Posix stuff is completely missing though. For an example where Bionic is not posix compliant: https://github.com/android/platform_bionic/blob/master/libc/docs/OVERVIEW.TXT "Note that Posix mandates a minimum of 128 slots, but we do not claim to be Posix-compliant." Most of the time Android uses Posix APIs. But if they think a function is not necessary, they just don't implement it. (For example wide character/wchar routines are not implemented on Android. It's not needed for JAVA Apps)
Jul 25 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-07-25 19:35, Johannes Pfau wrote:

 * Android doesn't officially support native executables. I'm not sure
    where this statement is hidden, but it is an official statement. For
    example their linker is broken when accessing a global variable from
    a native application in a specific way. Just to emphasize how bad
    this really is: If you want to access stdout (the C global variable)
    which is used in writeln for example, you have to use hacks and
    dladdr to load the address of stdout. You can't simply declare it as
    external. So you can't actually write a hello world native
    exacutalbe with D for Android. The Android devs don't care about
    those issues, as native executables are not supported anyway.
    But you wouldn't want to use native executables anyway. For example
    native executables have no possibility to draw a GUI. There's just no
    way to access the required window handle from a native executable.
    Instead the supported way to write a "Native Application" is to write
    a Java stub which loads a shared .so library and calls functions of
    that library. With recent versions of Android/NDK you don't have to
    write that stub yourself, it's included in the "NativeApplication"
    but it still works the same way: Java code loads a .so library.
    Which leads to the next problem:
I just have to say, that is so wrong on so many levels. -- /Jacob Carlborg
Jul 25 2012
parent reply "angel" <andrey.gelman gmail.com> writes:
As Android is mostly targeted at ARM, you could possibly target 
your spare time and good intentions to ARM as well.
1) Compile your code statically with whatever compiler you wish 
(e.g. GCC). Should work as long you don't interfere with 
Dalvik-controlled UI. Statically compiled C code works fine, 
there is no reason D should not.
2) Compile your code against 'bionic' - Android's analogue of 
glibc.
This would be a very (to say the least) demanding task.
3) After completing 1 and 2, you could possibly start to look at 
NDK - Android's native development kit, that has a well-defined 
API with the Java.

I would not seriously consider coding in D instead of Java. 
Neither D, Java nor Android are close to that.

Check out 'trimslice' as a possible development platform for ARM.
Jul 29 2012
parent reply Matthew Caron <Matt.Caron redlion.net> writes:
On 07/29/2012 10:30 AM, angel wrote:
 I would not seriously consider coding in D instead of Java. Neither D,
 Java nor Android are close to that.
I was thinking on this a bit. What if someone wrote a compiler target that compiled D to JVM bytecode? I know there are other compilers which do similar things. -- Matthew Caron, Software Build Engineer Sixnet, a Red Lion business | www.sixnet.com +1 (518) 877-5173 x138 office
Aug 03 2012
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 3 August 2012 at 12:41:37 UTC, Matthew Caron wrote:
 On 07/29/2012 10:30 AM, angel wrote:
 I would not seriously consider coding in D instead of Java. 
 Neither D,
 Java nor Android are close to that.
I was thinking on this a bit. What if someone wrote a compiler target that compiled D to JVM bytecode? I know there are other compilers which do similar things.
Then your code will be just Dalvik bytecode, with some of it being JITed depending on specific hotspots. The only benefit is to compile directly to native code. -- Paulo
Aug 05 2012
parent Matthew Caron <Matt.Caron redlion.net> writes:
On 08/05/2012 11:19 AM, Paulo Pinto wrote:
 I was thinking on this a bit. What if someone wrote a compiler target
 that compiled D to JVM bytecode? I know there are other compilers
 which do similar things.
Then your code will be just Dalvik bytecode, with some of it being JITed depending on specific hotspots. The only benefit is to compile directly to native code.
I'd argue that it depends on what you want to do. If one wants to have some D code which supports multiple platforms, and performance is a secondary consideration, than this may be a viable approach. -- Matthew Caron, Software Build Engineer Sixnet, a Red Lion business | www.sixnet.com +1 (518) 877-5173 x138 office
Aug 06 2012