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

	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

 	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)

	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

 	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)

 	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