Is D currently mature enough to create binaries for android/iOS? I've been researching this, but most posts predate 2013, and I wanted to know what was the current status.

D bindings for the JNI is certainly possible, so by extension it should be possible to call D libraries with Android's NDK, correct?

Is is possible to write android apps purely in D similar to mono for android?

http://developer.xamarin.com/guides/android/getting_started/hello,android/hello,android_quickstart/

On 25/02/2015 2:44 a.m., Rishub Nagpal wrote:
> Is D currently mature enough to create binaries for android/iOS? I've
> been researching this, but most posts predate 2013, and I wanted to know
> what was the current status.
>
> D bindings for the JNI is certainly possible, so by extension it should
> be possible to call D libraries with Android's NDK, correct?
>
> Is is possible to write android apps purely in D similar to mono for
> android?
>
> http://developer.xamarin.com/guides/android/getting_started/hello,android/hello,android_quickstart/

On the note of D -> Java / Java -> D bindings.
I have done a bit of work on my fork of djvm https://github.com/rikkimax/djvm/blob/master/source/wrappers/java/lang/String.d

Fields and static fields should also work at this time.
But it is a long way off production.

On Tuesday, 24 February 2015 at 13:44:07 UTC, Rishub Nagpal wrote:
> Is D currently mature enough to create binaries for android/iOS? I've been researching this, but most posts predate 2013, and I wanted to know what was the current status.

Mature enough?  Sure, but that doesn't mean the support is there.

> D bindings for the JNI is certainly possible, so by extension it should be possible to call D libraries with Android's NDK, correct?

If you simply want to call a D library within an Android/iOS app, that's possible, though there are still some rough edges.  Specifically, there is still some work to be done with certain floating-point operations on iOS (http://forum.dlang.org/post/m2mw4tab0w.fsf@comcast.net) and while Android/x86 will work fine (http://wiki.dlang.org/Build_DMD_for_Android), Android/ARM doesn't currently support TLS.  That lack of TLS support means you'd have to run a slightly patched druntime and I'm fairly certain phobos wouldn't work.

> Is is possible to write android apps purely in D similar to mono for android?
>
> http://developer.xamarin.com/guides/android/getting_started/hello,android/hello,android_quickstart/

I have ported a simple, purely C GUI app to D on Android/x86, as you can see in my wiki link.  However, there is a pthreads issue that needs to be fixed for bigger apps and there is no pre-baked GUI support yet for D on Android, certainly not anything like Xamarin.  You could call the OpenGL ES APIs yourself or port some GUI library that targets them, but I don't know of anybody who has done so on Android or iOS.

On Tuesday, 24 February 2015 at 17:15:28 UTC, Joakim wrote:
> On Tuesday, 24 February 2015 at 13:44:07 UTC, Rishub Nagpal wrote:
>> Is D currently mature enough to create binaries for android/iOS? I've been researching this, but most posts predate 2013, and I wanted to know what was the current status.
>
> Mature enough?  Sure, but that doesn't mean the support is there.
>
>> D bindings for the JNI is certainly possible, so by extension it should be possible to call D libraries with Android's NDK, correct?
>
> If you simply want to call a D library within an Android/iOS app, that's possible, though there are still some rough edges.  Specifically, there is still some work to be done with certain floating-point operations on iOS (http://forum.dlang.org/post/m2mw4tab0w.fsf@comcast.net) and while Android/x86 will work fine (http://wiki.dlang.org/Build_DMD_for_Android), Android/ARM doesn't currently support TLS.  That lack of TLS support means you'd have to run a slightly patched druntime and I'm fairly certain phobos wouldn't work.


Could any of these patches be used as a basis to remedy it?

https://groups.google.com/forum/#!topic/0xlab-devel/aSOcm3c9PFk
https://bugs.kde.org/show_bug.cgi?id=302709

Could you in theory recompile Android to support TLS and then try to compile an executable for Android/ARM ?

On Tuesday, 24 February 2015 at 13:44:07 UTC, Rishub Nagpal wrote:
> Is D currently mature enough to create binaries for android/iOS? I've been researching this, but most posts predate 2013, and I wanted to know what was the current status.
>
> D bindings for the JNI is certainly possible, so by extension it should be possible to call D libraries with Android's NDK, correct?
>
> Is is possible to write android apps purely in D similar to mono for android?
>
> http://developer.xamarin.com/guides/android/getting_started/hello,android/hello,android_quickstart/

FWIW, here's a current thread on the status of iOS support in LDC:

http://forum.dlang.org/thread/m2mw4tab0w.fsf@comcast.net

On Tuesday, 24 February 2015 at 17:55:59 UTC, Rishub Nagpal wrote:
> On Tuesday, 24 February 2015 at 17:15:28 UTC, Joakim wrote:
>> If you simply want to call a D library within an Android/iOS app, that's possible, though there are still some rough edges.
>>  Specifically, there is still some work to be done with certain floating-point operations on iOS (http://forum.dlang.org/post/m2mw4tab0w.fsf@comcast.net) and while Android/x86 will work fine (http://wiki.dlang.org/Build_DMD_for_Android), Android/ARM doesn't currently support TLS.  That lack of TLS support means you'd have to run a slightly patched druntime and I'm fairly certain phobos wouldn't work.
>
>
> Could any of these patches be used as a basis to remedy it?
>
> https://groups.google.com/forum/#!topic/0xlab-devel/aSOcm3c9PFk
> https://bugs.kde.org/show_bug.cgi?id=302709
>
> Could you in theory recompile Android to support TLS and then try to compile an executable for Android/ARM ?

Sorry, the way I wrote that may have been confusing: I meant that ldc doesn't currently support any form of TLS for Android/ARM.

Native TLS is not supported on Android/bionic for any architecture, whether x86 or ARM.  I worked around this on x86 by removing the SHF_TLS and STT_TLS flags from the ELF objects and using pthread_setspecific/pthread_getspecific instead (more details on the dmd PR: https://github.com/D-Programming-Language/dmd/pull/3643), which is basically how Walter implemented TLS on OS X/Mach-O years ago, as OS X didn't support native TLS till 10.7 and their TLV APIs are still undocumented.

I need to patch llvm in a similar way to that dmd PR, so that Android/ARM can use the same scheme.  It appears that Dan did something similar with his patched llvm for iOS.

As for your linked Android patches, that might be possible but would be pointless unless you are only deploying to a device you patched the OS for.  Better to patch llvm to support the same TLS scheme used for Android/x86.

On Tuesday, 24 February 2015 at 19:34:15 UTC, Joakim wrote:
> On Tuesday, 24 February 2015 at 17:55:59 UTC, Rishub Nagpal wrote:
>> On Tuesday, 24 February 2015 at 17:15:28 UTC, Joakim wrote:
>>> If you simply want to call a D library within an Android/iOS app, that's possible, though there are still some rough edges.
>>> Specifically, there is still some work to be done with certain floating-point operations on iOS (http://forum.dlang.org/post/m2mw4tab0w.fsf@comcast.net) and while Android/x86 will work fine (http://wiki.dlang.org/Build_DMD_for_Android), Android/ARM doesn't currently support TLS.  That lack of TLS support means you'd have to run a slightly patched druntime and I'm fairly certain phobos wouldn't work.
>>
>>
>> Could any of these patches be used as a basis to remedy it?
>>
>> https://groups.google.com/forum/#!topic/0xlab-devel/aSOcm3c9PFk
>> https://bugs.kde.org/show_bug.cgi?id=302709
>>
>> Could you in theory recompile Android to support TLS and then try to compile an executable for Android/ARM ?
>
> Sorry, the way I wrote that may have been confusing: I meant that ldc doesn't currently support any form of TLS for Android/ARM.
>
> Native TLS is not supported on Android/bionic for any architecture, whether x86 or ARM.  I worked around this on x86 by removing the SHF_TLS and STT_TLS flags from the ELF objects and using pthread_setspecific/pthread_getspecific instead (more details on the dmd PR: https://github.com/D-Programming-Language/dmd/pull/3643), which is basically how Walter implemented TLS on OS X/Mach-O years ago, as OS X didn't support native TLS till 10.7 and their TLV APIs are still undocumented.
>
> I need to patch llvm in a similar way to that dmd PR, so that Android/ARM can use the same scheme.  It appears that Dan did something similar with his patched llvm for iOS.
>
> As for your linked Android patches, that might be possible but would be pointless unless you are only deploying to a device you patched the OS for.  Better to patch llvm to support the same TLS scheme used for Android/x86.

Interesting. A few others and I were talking about getting
Android/ARM to function with LDC today. I'll be sure to keep up
to date with your work!

On Tuesday, 24 February 2015 at 21:20:24 UTC, Rishub Nagpal wrote:
> On Tuesday, 24 February 2015 at 19:34:15 UTC, Joakim wrote:
>> I need to patch llvm in a similar way to that dmd PR, so that Android/ARM can use the same scheme.  It appears that Dan did something similar with his patched llvm for iOS.
>>
>> As for your linked Android patches, that might be possible but would be pointless unless you are only deploying to a device you patched the OS for.  Better to patch llvm to support the same TLS scheme used for Android/x86.
>
> Interesting. A few others and I were talking about getting
> Android/ARM to function with LDC today. I'll be sure to keep up
> to date with your work!

The remaining piece is to insert the correct function call to ___tls_get_addr when TLS variables are accessed, ie the equivalent to this patch for dmd's backend needs to be created for llvm:

https://github.com/joakim-noah/dmd/commit/477f52cffb0d8bd1a698dd33ad7e2e66d9fa62ca#diff-d427199c5cd504da634c0c42fc2b3371

I've been putting off looking into llvm's internals enough to write that for a while now.  If you or anybody else knows llvm better, feel free to take it.  The remaining changes needed are in this small patch for llvm:

https://gist.github.com/joakim-noah/1fb23fba1ba5b7e87e1a

On Wednesday, 25 February 2015 at 08:04:02 UTC, Joakim wrote:
> On Tuesday, 24 February 2015 at 21:20:24 UTC, Rishub Nagpal wrote:
>> On Tuesday, 24 February 2015 at 19:34:15 UTC, Joakim wrote:
>>> I need to patch llvm in a similar way to that dmd PR, so that Android/ARM can use the same scheme.  It appears that Dan did something similar with his patched llvm for iOS.
>>>
>>> As for your linked Android patches, that might be possible but would be pointless unless you are only deploying to a device you patched the OS for.  Better to patch llvm to support the same TLS scheme used for Android/x86.
>>
>> Interesting. A few others and I were talking about getting
>> Android/ARM to function with LDC today. I'll be sure to keep up
>> to date with your work!
>
> The remaining piece is to insert the correct function call to ___tls_get_addr when TLS variables are accessed, ie the equivalent to this patch for dmd's backend needs to be created for llvm:
>
> https://github.com/joakim-noah/dmd/commit/477f52cffb0d8bd1a698dd33ad7e2e66d9fa62ca#diff-d427199c5cd504da634c0c42fc2b3371
>
> I've been putting off looking into llvm's internals enough to write that for a while now.  If you or anybody else knows llvm better, feel free to take it.  The remaining changes needed are in this small patch for llvm:
>
> https://gist.github.com/joakim-noah/1fb23fba1ba5b7e87e1a

Cool. I will take a look

On Wednesday, 25 February 2015 at 08:04:02 UTC, Joakim wrote:
> On Tuesday, 24 February 2015 at 21:20:24 UTC, Rishub Nagpal wrote:
>> On Tuesday, 24 February 2015 at 19:34:15 UTC, Joakim wrote:
>>> I need to patch llvm in a similar way to that dmd PR, so that Android/ARM can use the same scheme.  It appears that Dan did something similar with his patched llvm for iOS.
>>>
>>> As for your linked Android patches, that might be possible but would be pointless unless you are only deploying to a device you patched the OS for.  Better to patch llvm to support the same TLS scheme used for Android/x86.
>>
>> Interesting. A few others and I were talking about getting
>> Android/ARM to function with LDC today. I'll be sure to keep up
>> to date with your work!
>
> The remaining piece is to insert the correct function call to ___tls_get_addr when TLS variables are accessed, ie the equivalent to this patch for dmd's backend needs to be created for llvm:
>
> https://github.com/joakim-noah/dmd/commit/477f52cffb0d8bd1a698dd33ad7e2e66d9fa62ca#diff-d427199c5cd504da634c0c42fc2b3371
>
> I've been putting off looking into llvm's internals enough to write that for a while now.  If you or anybody else knows llvm better, feel free to take it.  The remaining changes needed are in this small patch for llvm:
>
> https://gist.github.com/joakim-noah/1fb23fba1ba5b7e87e1a

Why exactly do we need to insert that TLS function call? Shouldn't Android/ARM follow the normal ELF logic? I am not really sure what Dan Olsen did here:

https://github.com/smolt/llvm/commit/42c2d7057b62454bb466abe8d146dd3c717e2cc5

Is he creating a iOS TLS ABI?


I have spent the last week doing heavy research, and I am not sure if I really understand the problem

Do you have any references or documented code I can read to better understand what exactly is going on?