www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What is the state of D with Android/iOS

reply "Rishub Nagpal" <rishubster gmail.com> writes:
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/
Feb 24 2015
next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
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.
Feb 24 2015
prev sibling next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
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.
Feb 24 2015
parent reply "Rishub Nagpal" <rishubster gmail.com> writes:
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 ?
Feb 24 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
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.
Feb 24 2015
parent reply "Rishub Nagpal" <rishubster gmail.com> writes:
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!
Feb 24 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
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
Feb 25 2015
next sibling parent "Rishub Nagpal" <rishubster gmail.com> writes:
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
Feb 25 2015
prev sibling parent reply "Rishub Nagpal" <rishubster gmail.com> writes:
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?
Mar 03 2015
next sibling parent reply Dan Olson <zans.is.for.cans yahoo.com> writes:
"Rishub Nagpal" <rishubster gmail.com> writes:

 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?
I haven't been following this discussion, so forgive me if this is way off. I think LDC/LLVM should work as-is for Android/ARM if you are happy with linux thread local sections and lookup func. For iOS the situation is a bit worse since LLVM did not have code to generate the TLS lookup function, but it did know how to generate Mach-O TLS sections. For Android, LDC generates the usual .tbss/.tdata sections for TLS vars and __aeabi_read_tp() when needed to lookup the base address. ldc2 -mtriple=thumbv7-linux-anrdoideabi -output-s test.d tlsvar = 42; ldr r1, .LCPI1_0 movs r2, #42 bl __aeabi_read_tp str r2, [r0, r1] For iOS, I then added what was missing from the OS loader to find TLS sections and provide the lookup function to lazy init TLS block and return address. These are just linked in with the app instead being provided by OS libs and kernel. At that point, it looked to ldc_sections.d like normal OSX TLS. I would guess you could do the same for Android/ARM with LDC and make it look like linux to ld_sections. -- Dan
Mar 03 2015
parent reply Dan Olson <zans.is.for.cans yahoo.com> writes:
Dan Olson <zans.is.for.cans yahoo.com> writes:
 For Android, LDC generates the usual .tbss/.tdata sections for TLS vars
 and __aeabi_read_tp() when needed to lookup the base address.

   ldc2 -mtriple=thumbv7-linux-anrdoideabi -output-s test.d 

   tlsvar = 42;

 	ldr	r1, .LCPI1_0
 	movs	r2, #42
 	bl	__aeabi_read_tp
 	str	r2, [r0, r1]

 For iOS, I then added what was missing from the OS loader to find TLS
 sections and provide the lookup function to lazy init TLS block and
 return address.  These are just linked in with the app instead being
 provided by OS libs and kernel.  At that point, it looked to
 ldc_sections.d like normal OSX TLS.

 I would guess you could do the same for Android/ARM with LDC and make it
 look like linux to ld_sections.
As PIC: ldc2 -mtriple=thumbv7-linux-androideabi -output-s -relocation-model=pic -O tls1.d ldr r0, .LCPI1_0 .LPC1_0: add r0, pc bl __tls_get_addr(PLT) movs r1, #42 str r1, [r0] Shouldn't that work?
Mar 04 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Wednesday, 4 March 2015 at 17:31:49 UTC, Dan Olson wrote:
 Dan Olson <zans.is.for.cans yahoo.com> writes:
 For Android, LDC generates the usual .tbss/.tdata sections for 
 TLS vars
 and __aeabi_read_tp() when needed to lookup the base address.

   ldc2 -mtriple=thumbv7-linux-anrdoideabi -output-s test.d

   tlsvar = 42;

 	ldr	r1, .LCPI1_0
 	movs	r2, #42
 	bl	__aeabi_read_tp
 	str	r2, [r0, r1]

 For iOS, I then added what was missing from the OS loader to 
 find TLS
 sections and provide the lookup function to lazy init TLS 
 block and
 return address.  These are just linked in with the app instead 
 being
 provided by OS libs and kernel.  At that point, it looked to
 ldc_sections.d like normal OSX TLS.

 I would guess you could do the same for Android/ARM with LDC 
 and make it
 look like linux to ld_sections.
As PIC: ldc2 -mtriple=thumbv7-linux-androideabi -output-s -relocation-model=pic -O tls1.d ldr r0, .LCPI1_0 .LPC1_0: add r0, pc bl __tls_get_addr(PLT) movs r1, #42 str r1, [r0] Shouldn't that work?
Maybe the inserted function call will work- I'm not familiar with ARM assembly, so I can't say for sure- but I'm guessing it's passing a different pointer to the function, which I noted above. Some modifications will likely need to be made to llvm to support the packed TLS scheme used so far, with dmd for Android/x86.
Mar 04 2015
parent reply "Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes:
BTW - since we have linux on ARM, the following may be useful if 
you wish to run a D application on your Android mobile device.  
No ADB or root required.

http://kevinboone.net/android_nonroot.html

I guess you might be able to run a local web server to have a 
friendlier interface, although I have not yet tried.  Since ssh 
and rsync works, I don't see why a web server wouldn't.

Only thing is that I don't think vibe.d is available on ARM yet.  
(Please correct me if I am wrong).

The alternative is to run a full linux install in a chroot:

https://play.google.com/store/apps/details?id=ru.meefik.linuxdeploy
Apr 12 2015
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Sunday, 12 April 2015 at 19:03:33 UTC, Laeeth Isharc wrote:
 BTW - since we have linux on ARM, the following may be useful 
 if you wish to run a D application on your Android mobile 
 device.  No ADB or root required.

 http://kevinboone.net/android_nonroot.html

 I guess you might be able to run a local web server to have a 
 friendlier interface, although I have not yet tried.  Since ssh 
 and rsync works, I don't see why a web server wouldn't.

 Only thing is that I don't think vibe.d is available on ARM 
 yet.  (Please correct me if I am wrong).

 The alternative is to run a full linux install in a chroot:

 https://play.google.com/store/apps/details?id=ru.meefik.linuxdeploy
I am pretty sure I remember people reporting running vibe.d on Raspberry Pi It is not checked by CI so things can break time to time, but in general it should work
Apr 12 2015
next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Monday, 13 April 2015 at 05:57:24 UTC, Dicebot wrote:
 On Sunday, 12 April 2015 at 19:03:33 UTC, Laeeth Isharc wrote:
 BTW - since we have linux on ARM, the following may be useful 
 if you wish to run a D application on your Android mobile 
 device.  No ADB or root required.

 http://kevinboone.net/android_nonroot.html

 I guess you might be able to run a local web server to have a 
 friendlier interface, although I have not yet tried.  Since 
 ssh and rsync works, I don't see why a web server wouldn't.

 Only thing is that I don't think vibe.d is available on ARM 
 yet.  (Please correct me if I am wrong).

 The alternative is to run a full linux install in a chroot:

 https://play.google.com/store/apps/details?id=ru.meefik.linuxdeploy
I am pretty sure I remember people reporting running vibe.d on Raspberry Pi It is not checked by CI so things can break time to time, but in general it should work
Is there a need for people running tests on Raspberry Pis? I'm planning on picking up the new version in a few days, was unaware D even really worked on ARM.
Apr 12 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 13 April 2015 at 06:37:34 UTC, weaselcat wrote:
 Is there a need for people running tests on Raspberry Pis? I'm 
 planning on picking up the new version in a few days, was 
 unaware D even really worked on ARM.
Currently vibe.d uses Travis CI so unless it gets replaced with some self-hosted CI solution I don't think anything can really be done here right now. Well, apart from trying it out and reporting bugs if there are any :)
Apr 12 2015
parent Johannes Pfau <nospam example.com> writes:
Am Mon, 13 Apr 2015 06:45:35 +0000
schrieb "Dicebot" <public dicebot.lv>:

 On Monday, 13 April 2015 at 06:37:34 UTC, weaselcat wrote:
 Is there a need for people running tests on Raspberry Pis? I'm 
 planning on picking up the new version in a few days, was 
 unaware D even really worked on ARM.
Currently vibe.d uses Travis CI so unless it gets replaced with some self-hosted CI solution I don't think anything can really be done here right now. Well, apart from trying it out and reporting bugs if there are any :)
It's possible to emulate ARM using qemu on travis-ci: http://www.tomaz.me/2013/12/02/running-travis-ci-tests-on-arm.html Of course it's not exactly fast ;-)
Apr 13 2015
prev sibling next sibling parent Mathias Lang via Digitalmars-d <digitalmars-d puremagic.com> writes:
2015-04-13 7:57 GMT+02:00 Dicebot via Digitalmars-d <
digitalmars-d puremagic.com>:

 On Sunday, 12 April 2015 at 19:03:33 UTC, Laeeth Isharc wrote:

 BTW - since we have linux on ARM, the following may be useful if you wish
 to run a D application on your Android mobile device.  No ADB or root
 required.

 http://kevinboone.net/android_nonroot.html

 I guess you might be able to run a local web server to have a friendlier
 interface, although I have not yet tried.  Since ssh and rsync works, I
 don't see why a web server wouldn't.

 Only thing is that I don't think vibe.d is available on ARM yet.  (Please
 correct me if I am wrong).

 The alternative is to run a full linux install in a chroot:

 https://play.google.com/store/apps/details?id=ru.meefik.linuxdeploy
I am pretty sure I remember people reporting running vibe.d on Raspberry Pi It is not checked by CI so things can break time to time, but in general it should work
I did compile and run a Vibe.d based solution on a Raspi B for almost 18 months. It was mainly for the client part though, but I didn't have any issue specific to Vibe.d.
Apr 13 2015
prev sibling parent "Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes:
Dicebot:
 I am pretty sure I remember people reporting running vibe.d on 
 Raspberry Pi
 It is not checked by CI so things can break time to time, but 
 in general it should work
Thanks. So currently for me - running arch linux within a chroot under android on a oneplusone phone - gdc seems to work fine for hello world. ldc now compiles and links (thanks, dicebot) but gives me a bus error when I try to run the code. clang compiles the C equivalent fine and the code works. vibed default/hw app compiles under gdc and starts, but cannot listen on the port and segfaults. it's possible it is an artefact of running linux within the chroot (although everything else I have tried works so far including vnc, python, numpy, etc) so will try on raspberry pi when I get around to ordering one (which may be some weeks). at a tangent: I think it is an easy win to write up a small tutorial on developing simple apps in D on android. obviously the retail market is big, but there is opportunity for enterprise users - many people on the portfolio manager side in the investment world would love to be able to see key calculations on their phone. it doesn't need to be super-pretty; just seeing the results in a browser would be a big improvement over nothing.
Apr 13 2015
prev sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Sunday, 12 April 2015 at 19:03:33 UTC, Laeeth Isharc wrote:
 BTW - since we have linux on ARM, the following may be useful 
 if you wish to run a D application on your Android mobile 
 device.  No ADB or root required.

 http://kevinboone.net/android_nonroot.html
I stumbled across that site sometime back when looking for a way to open a shell with my own command-line apps on my Android tablet and run the druntime/phobos unit tests from the command line on an unrooted Android/ARM device. However, that setup is not going to fix the TLS issue that's holding up Android/ARM. D sticks all non-shared/__gshared globals in Thread-Local Storage (TLS) by default, but Android doesn't support TLS natively, so you can't just compile a D app for linux/ARM and run it on Android/ARM, whether with that setup or not.
 I guess you might be able to run a local web server to have a 
 friendlier interface, although I have not yet tried.  Since ssh 
 and rsync works, I don't see why a web server wouldn't.
It'll likely work; you just can't run on port 80 because you don't have root.
 The alternative is to run a full linux install in a chroot:

 https://play.google.com/store/apps/details?id=ru.meefik.linuxdeploy
But that requires root, so you're back to square one.
Apr 13 2015
parent reply "Laeeth Isharc" <Laeeth.nospam nospam-laeeth.com> writes:
On Monday, 13 April 2015 at 16:33:06 UTC, Joakim wrote:
 On Sunday, 12 April 2015 at 19:03:33 UTC, Laeeth Isharc wrote:
 BTW - since we have linux on ARM, the following may be useful 
 if you wish to run a D application on your Android mobile 
 device.  No ADB or root required.

 http://kevinboone.net/android_nonroot.html
I stumbled across that site sometime back when looking for a way to open a shell with my own command-line apps on my Android tablet and run the druntime/phobos unit tests from the command line on an unrooted Android/ARM device. However, that setup is not going to fix the TLS issue that's holding up Android/ARM. D sticks all non-shared/__gshared globals in Thread-Local Storage (TLS) by default, but Android doesn't support TLS natively, so you can't just compile a D app for linux/ARM and run it on Android/ARM, whether with that setup or not.
So that is why vibed demo app doesn't work although it does compile. (The TLS kludge not yet in GDC). So if I make all globall gshared, I can do useful work today using Gdc on arm android, even if I have to use an alternative to vibed for the network stuff ?
 I guess you might be able to run a local web server to have a 
 friendlier interface, although I have not yet tried.  Since 
 ssh and rsync works, I don't see why a web server wouldn't.
It'll likely work; you just can't run on port 80 because you don't have root.
Fine with me to use another port... I am not trying to serve the world, just be able to interact via the browser rather than command line.
 The alternative is to run a full linux install in a chroot:

 https://play.google.com/store/apps/details?id=ru.meefik.linuxdeploy
But that requires root, so you're back to square one.
Well, I have root. But if I get somebody else to start playing with my app, I don't want to have to make them root their device just to see what it does. Laeeth.
Apr 13 2015
next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Mon, 13 Apr 2015 17:44:41 +0000
schrieb "Laeeth Isharc" <Laeeth.nospam nospam-laeeth.com>:

 On Monday, 13 April 2015 at 16:33:06 UTC, Joakim wrote:
 On Sunday, 12 April 2015 at 19:03:33 UTC, Laeeth Isharc wrote:
 BTW - since we have linux on ARM, the following may be useful 
 if you wish to run a D application on your Android mobile 
 device.  No ADB or root required.

 http://kevinboone.net/android_nonroot.html
I stumbled across that site sometime back when looking for a way to open a shell with my own command-line apps on my Android tablet and run the druntime/phobos unit tests from the command line on an unrooted Android/ARM device. However, that setup is not going to fix the TLS issue that's holding up Android/ARM. D sticks all non-shared/__gshared globals in Thread-Local Storage (TLS) by default, but Android doesn't support TLS natively, so you can't just compile a D app for linux/ARM and run it on Android/ARM, whether with that setup or not.
So that is why vibed demo app doesn't work although it does compile. (The TLS kludge not yet in GDC). So if I make all globall gshared, I can do useful work today using Gdc on arm android, even if I have to use an alternative to vibed for the network stuff ?
I didn't read all of this discussion. Does the chroot method mean you can use glibc? Anyway, I recently pushed GC support for GCC emulated TLS to GDC which should work just fine on bionic or glibc. However, the GC doesn't work with bionic because of other issues. So your best bet is to build an ARM GDC-compiler with --disable-tls. This way you at least get emulated TLS which should work.
Apr 13 2015
parent "Laeeth Isharc" <Laeeth.nospam nospam-laeeth.com> writes:
On Monday, 13 April 2015 at 18:30:16 UTC, Johannes Pfau wrote:
 Am Mon, 13 Apr 2015 17:44:41 +0000
 schrieb "Laeeth Isharc" <Laeeth.nospam nospam-laeeth.com>:

 On Monday, 13 April 2015 at 16:33:06 UTC, Joakim wrote:
 On Sunday, 12 April 2015 at 19:03:33 UTC, Laeeth Isharc 
 wrote:
 BTW - since we have linux on ARM, the following may be 
 useful if you wish to run a D application on your Android 
 mobile device.  No ADB or root required.

 http://kevinboone.net/android_nonroot.html
I stumbled across that site sometime back when looking for a way to open a shell with my own command-line apps on my Android tablet and run the druntime/phobos unit tests from the command line on an unrooted Android/ARM device. However, that setup is not going to fix the TLS issue that's holding up Android/ARM. D sticks all non-shared/__gshared globals in Thread-Local Storage (TLS) by default, but Android doesn't support TLS natively, so you can't just compile a D app for linux/ARM and run it on Android/ARM, whether with that setup or not.
So that is why vibed demo app doesn't work although it does compile. (The TLS kludge not yet in GDC). So if I make all globall gshared, I can do useful work today using Gdc on arm android, even if I have to use an alternative to vibed for the network stuff ?
I didn't read all of this discussion. Does the chroot method mean you can use glibc?
Yes - I think so. Otherwise I presume the standard ARM arch distribution (which is running on my phone under the open source project "Linux Deploy" wouldn't work. I don't know what dark magic, if any, is done to make this project function more generally. Anyway, I recently pushed GC support for GCC
 emulated
 TLS to GDC which should work just fine on bionic or glibc. 
 However, the
 GC doesn't work with bionic because of other issues.

 So your best bet is to build an ARM GDC-compiler with 
 --disable-tls.
 This way you at least get emulated TLS which should work.
Thank you for this. I will give it a try.
Apr 13 2015
prev sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Monday, 13 April 2015 at 17:44:42 UTC, Laeeth Isharc wrote:
 On Monday, 13 April 2015 at 16:33:06 UTC, Joakim wrote:
 So that is why vibed demo app doesn't work although it does 
 compile.   (The TLS kludge not yet in GDC).  So if I make all 
 globall gshared, I can do useful work today using Gdc on arm 
 android, even if I have to use an alternative to vibed for the 
 network stuff ?
Yes, but that is harder than it sounds, because often those globals are supposed to be thread-local. Dan Olson has a branch of druntime for iOS where he uses pthreads instead for TLS, for the handful of places where druntime needs it: https://github.com/smolt/druntime/blob/ios/src/ldc/xyzzy.d#L83 Phobos uses TLS globals much more, so it's prohibitive to do the same there. That means you could use druntime but not phobos if you wanted to go this route, as I mentioned to Rishub earlier in this thread.
 The alternative is to run a full linux install in a chroot:

 https://play.google.com/store/apps/details?id=ru.meefik.linuxdeploy
But that requires root, so you're back to square one.
Well, I have root. But if I get somebody else to start playing with my app, I don't want to have to make them root their device just to see what it does.
Yep, one of the many problems with root. On Monday, 13 April 2015 at 18:30:16 UTC, Johannes Pfau wrote:
 I didn't read all of this discussion. Does the chroot method 
 mean you
 can use glibc?
Yes, I believe so.
Apr 13 2015
parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Tuesday, 14 April 2015 at 04:07:29 UTC, Joakim wrote:
 On Monday, 13 April 2015 at 17:44:42 UTC, Laeeth Isharc wrote:
 On Monday, 13 April 2015 at 16:33:06 UTC, Joakim wrote:
 So that is why vibed demo app doesn't work although it does 
 compile.   (The TLS kludge not yet in GDC).  So if I make all 
 globall gshared, I can do useful work today using Gdc on arm 
 android, even if I have to use an alternative to vibed for the 
 network stuff ?
Yes, but that is harder than it sounds, because often those globals are supposed to be thread-local. Dan Olson has a branch of druntime for iOS where he uses pthreads instead for TLS, for the handful of places where druntime needs it: https://github.com/smolt/druntime/blob/ios/src/ldc/xyzzy.d#L83 Phobos uses TLS globals much more, so it's prohibitive to do the same there. That means you could use druntime but not phobos if you wanted to go this route, as I mentioned to Rishub earlier in this thread.
 The alternative is to run a full linux install in a chroot:

 https://play.google.com/store/apps/details?id=ru.meefik.linuxdeploy
But that requires root, so you're back to square one.
Well, I have root. But if I get somebody else to start playing with my app, I don't want to have to make them root their device just to see what it does.
Yep, one of the many problems with root. On Monday, 13 April 2015 at 18:30:16 UTC, Johannes Pfau wrote:
 I didn't read all of this discussion. Does the chroot method 
 mean you
 can use glibc?
Yes, I believe so.
You can use glibc with the Android NDK anyway. Atila
Apr 14 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Tuesday, 14 April 2015 at 08:55:50 UTC, Atila Neves wrote:
 On Tuesday, 14 April 2015 at 04:07:29 UTC, Joakim wrote:
 On Monday, 13 April 2015 at 18:30:16 UTC, Johannes Pfau wrote:
 I didn't read all of this discussion. Does the chroot method 
 mean you
 can use glibc?
Yes, I believe so.
You can use glibc with the Android NDK anyway.
Meaning you statically link glibc into your native Android app and avoid bionic? Maybe that's possible, dunno.
Apr 14 2015
parent "Atila Neves" <atila.neves gmail.com> writes:
On Tuesday, 14 April 2015 at 10:38:02 UTC, Joakim wrote:
 On Tuesday, 14 April 2015 at 08:55:50 UTC, Atila Neves wrote:
 On Tuesday, 14 April 2015 at 04:07:29 UTC, Joakim wrote:
 On Monday, 13 April 2015 at 18:30:16 UTC, Johannes Pfau wrote:
 I didn't read all of this discussion. Does the chroot method 
 mean you
 can use glibc?
Yes, I believe so.
You can use glibc with the Android NDK anyway.
Meaning you statically link glibc into your native Android app and avoid bionic? Maybe that's possible, dunno.
It's a makefile option somewhere. I had to do it a few years ago because we needed a full libc and the C++ standard library. I always get confused when people say Android uses a different libc. It does that by default, bionic isn't the only option and IIRC glibc isn't the only alternative either. Atila
Apr 15 2015
prev sibling parent "Joakim" <dlang joakim.fea.st> writes:
On Tuesday, 3 March 2015 at 21:20:35 UTC, Rishub Nagpal wrote:
 On Wednesday, 25 February 2015 at 08:04:02 UTC, Joakim wrote:
 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?
I referred you to my dmd PR above with more details. The third comment there goes over it all, with additional links to articles and the TLS implementation in druntime for Android: https://github.com/D-Programming-Language/dmd/pull/3643#issuecomment-45479519 As I said before, Android does not support native TLS, just as OS X did not when Walter wrote his TLS implementation for OS X. If you read his article, you will get the idea of what we're doing. In any case, you don't really need to understand everything in order to add the missing piece. Similar to how llvm already adds a call to ___tls_get_addr(tls_index* ti) when compiled with PIC, we need to add a call to ___tls_get_addr(void* p) when a TLS variable is invoked to pull the right pointer offset in our Android scheme. Right now, I'm just trying it on x86, as you can see in my gist above, before attempting the same on ARM. If you or someone else is already familiar with llvm internals, they can do this quicker than me. If not, I'll get to it eventually.
Mar 04 2015
prev sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
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
Feb 24 2015