May 10, 2015
On Friday, 8 May 2015 at 16:42:21 UTC, Dan Olson wrote:
> Joakim, the ldc merge-2.067 branch works well and has updated
> druntime/phobos.  I know it has some of your Android updates.  You may
> have more fun working with it.

OK, I'll try it.  I didn't want to run into bugs unrelated to cross-compiling, so I hadn't tried it yet.

> I wonder if we should keep a common LLVM fork with changes to support D
> on targets without builtin TLS?  I did another LLVM hack in x86 backend
> to support TLS on iPhone sim, and have been thinking about adding a
> fallback TLS, like emulated tls that gcc and gdc has, to support TLS
> using a target plugin to get lookup address.  That way it could be wired
> into any old embedded multi thread RTOS with some sort of thread-local
> support.
>
> Maybe someday could even get LLVM to accept some patches.

Sounds like a worthwhile idea, though my patches to llvm are minimal.  I'm sure they'd seriously consider accepting such patches, since the gcc backend already has this built in.

I just checked last week and the recent Android NDK's gcc has emulated TLS enabled by default, while the same C/C++ source employing TLS __thread and compiled with the NDK's clang will segfault because it doesn't have emulated TLS.  Emulated TLS wasn't added to the NDK's gcc by google either: it appears to have just slipped in from upstream, which is perhaps why they seem to be unaware that it works for one compiler in the NDK and not the other.

Let the llvm guys know of this disparity, and I'm sure they'll be up for remedying it.
May 18, 2015
"Joakim" <dlang@joakim.fea.st> writes:

> I just checked last week and the recent Android NDK's gcc has emulated TLS enabled by default, while the same C/C++ source employing TLS __thread and compiled with the NDK's clang will segfault because it doesn't have emulated TLS.  Emulated TLS wasn't added to the NDK's gcc by google either: it appears to have just slipped in from upstream, which is perhaps why they seem to be unaware that it works for one compiler in the NDK and not the other.
>
> Let the llvm guys know of this disparity, and I'm sure they'll be up for remedying it.

Just out of curiosity, shouldn't GDC then be better suited for Android than LDC? LDC works well with iOS only because Apple contributes to LLVM.

Later, mid-summer perhaps, I plan to get both iOS and Android arm64 devicse so will be joining in the effort. I have too much other stuff going on now though outside of D-Land and have to stick to little D projects that won't vacuum away an afternoon.
-- 
Dan
May 18, 2015
On Monday, 18 May 2015 at 14:30:54 UTC, Dan Olson wrote:
> "Joakim" <dlang@joakim.fea.st> writes:
>
>> I just checked last week and the recent Android NDK's gcc has emulated
>> TLS enabled by default, while the same C/C++ source employing TLS
>> __thread and compiled with the NDK's clang will segfault because it
>> doesn't have emulated TLS.  Emulated TLS wasn't added to the NDK's gcc
>> by google either: it appears to have just slipped in from upstream,
>> which is perhaps why they seem to be unaware that it works for one
>> compiler in the NDK and not the other.
>>
>> Let the llvm guys know of this disparity, and I'm sure they'll be up
>> for remedying it.
>
> Just out of curiosity, shouldn't GDC then be better suited for Android
> than LDC? LDC works well with iOS only because Apple contributes to
> LLVM.

I don't think it matters, as llvm works very well on linux and the changes google makes for Android to the NDK compilers are minimal:

https://android.googlesource.com/toolchain/llvm/+log/release_36
https://android.googlesource.com/toolchain/clang/+log/release_36

https://android.googlesource.com/toolchain/gcc/+log/master/gcc-4.9

The one difference is TLS using the __thread annotation, which was documented as unsupported by the Android NDK for a long time but now happens to work with gcc and not clang/llvm.  However, the gdc guys trying to use gcc's emulated TLS have reported problems getting it working with the GC.  Maybe that's since been fixed, but that's the last I heard.

> Later, mid-summer perhaps, I plan to get both iOS and Android arm64
> devicse so will be joining in the effort. I have too much other stuff
> going on now though outside of D-Land and have to stick to little D
> projects that won't vacuum away an afternoon.

Sure, have fun with your new devices. :) Hopefully, I'll get Android/ARM working before then, but I don't and won't have any AArch64 devices to test.  Not that it matters, as 64-bit ARM has even less share than x86 right now.
May 18, 2015
On Thursday, 7 May 2015 at 15:58:01 UTC, Joakim wrote:
> It's all a bit hacky right now, but I'll clean it up and submit PRs eventually.

Yes, please do. ;)

 — David
May 18, 2015
Am Mon, 18 May 2015 15:47:06 +0000
schrieb "Joakim" <dlang@joakim.fea.st>:

>  However,
> the gdc guys trying to use gcc's emulated TLS have reported
> problems getting it working with the GC.  Maybe that's since been
> fixed, but that's the last I heard.

We've fixed that in the meantime, emulated TLS is working fine. The main problem is making the GC fast with emulated TLS. For now we've implemented a slower but 100% correct solution which scans every TLS variable in every thread separately. (GCCs emutls doesn't use contiguous memory).

But IIRC to get a 2x collection slowdown compared to
native TLS you need 10_000s of TLS variables and many threads, so it
probably doesn't matter.
May 25, 2015
On Monday, 18 May 2015 at 15:47:07 UTC, Joakim wrote:
> Sure, have fun with your new devices. :) Hopefully, I'll get Android/ARM working before then, but I don't and won't have any AArch64 devices to test.  Not that it matters, as 64-bit ARM has even less share than x86 right now.

Earlier this week, I stumbled across a way to get TLS working with ldc for Android/ARM, similar to the approach used for Android/x86 so far.  Exception-handling on ARM for ldc is currently unfinished (https://github.com/ldc-developers/ldc/issues/489), so if I disable a handful of tests related to that, I get 36 of 42 druntime modules' unit tests and around 31 of 70 phobos modules' unit tests to pass.  All tests were run from the command line on my Android tablet.  It appears there are issues related to unicode and the GC causing many of the remaining failures.
July 30, 2015
On Monday, 25 May 2015 at 20:08:48 UTC, Joakim wrote:
> On Monday, 18 May 2015 at 15:47:07 UTC, Joakim wrote:
>> Sure, have fun with your new devices. :) Hopefully, I'll get Android/ARM working before then, but I don't and won't have any AArch64 devices to test.  Not that it matters, as 64-bit ARM has even less share than x86 right now.
>
> Earlier this week, I stumbled across a way to get TLS working with ldc for Android/ARM, similar to the approach used for Android/x86 so far.  Exception-handling on ARM for ldc is currently unfinished (https://github.com/ldc-developers/ldc/issues/489), so if I disable a handful of tests related to that, I get 36 of 42 druntime modules' unit tests and around 31 of 70 phobos modules' unit tests to pass.  All tests were run from the command line on my Android tablet.  It appears there are issues related to unicode and the GC causing many of the remaining failures.

Some good news, I've made progress on the port to Android/ARM, using ldc's 2.067 branch.  Currently, all 46 modules in druntime and 85 of 88 modules in phobos pass their tests (I had to comment out a few tests across four modules) when run on the command-line.  There is a GC issue that causes 2-3 other modules to hang only when the tests are run as part of an Android app/apk, ie a D shared library that's invoked by the Java runtime.

I've compiled an Android/ARM app that will run the remaining majority of tests on Android 5 Lollipop or newer, which you can download and try out on your Android 5 devices:

https://github.com/joakim-noah/android/releases/tag/apk

All tests run on my Android 5.1 device, while the last two modules tested by this app hang on an Android 5.0 device I tested.  All patches used are linked from the above release.
July 31, 2015
On Thursday, 30 July 2015 at 19:38:12 UTC, Joakim wrote:
> On Monday, 25 May 2015 at 20:08:48 UTC, Joakim wrote:
>> On Monday, 18 May 2015 at 15:47:07 UTC, Joakim wrote:
>>> Sure, have fun with your new devices. :) Hopefully, I'll get Android/ARM working before then, but I don't and won't have any AArch64 devices to test.  Not that it matters, as 64-bit ARM has even less share than x86 right now.
>>
>> Earlier this week, I stumbled across a way to get TLS working with ldc for Android/ARM, similar to the approach used for Android/x86 so far.  Exception-handling on ARM for ldc is currently unfinished (https://github.com/ldc-developers/ldc/issues/489), so if I disable a handful of tests related to that, I get 36 of 42 druntime modules' unit tests and around 31 of 70 phobos modules' unit tests to pass.  All tests were run from the command line on my Android tablet.  It appears there are issues related to unicode and the GC causing many of the remaining failures.
>
> Some good news, I've made progress on the port to Android/ARM, using ldc's 2.067 branch.  Currently, all 46 modules in druntime and 85 of 88 modules in phobos pass their tests (I had to comment out a few tests across four modules) when run on the command-line.  There is a GC issue that causes 2-3 other modules to hang only when the tests are run as part of an Android app/apk, ie a D shared library that's invoked by the Java runtime.
>
> I've compiled an Android/ARM app that will run the remaining majority of tests on Android 5 Lollipop or newer, which you can download and try out on your Android 5 devices:
>
> https://github.com/joakim-noah/android/releases/tag/apk
>
> All tests run on my Android 5.1 device, while the last two modules tested by this app hang on an Android 5.0 device I tested.  All patches used are linked from the above release.

Thanks, I didn't remember you were the one working on this. I've been following this and I'm just as eager to start testing my libraries with it.

I think Android could also use a cross-platform web plugin framework. I've started to refactor the idea, and just being able to enhance a website with native code on any platform would be great, it would really make up for being forced into doing all-javascript when writing the UI in HTML5/CSS right now.
July 31, 2015
On Thursday, 30 July 2015 at 19:38:12 UTC, Joakim wrote:
> On Monday, 25 May 2015 at 20:08:48 UTC, Joakim wrote:
>> [...]
>
> Some good news, I've made progress on the port to Android/ARM, using ldc's 2.067 branch.  Currently, all 46 modules in druntime and 85 of 88 modules in phobos pass their tests (I had to comment out a few tests across four modules) when run on the command-line.  There is a GC issue that causes 2-3 other modules to hang only when the tests are run as part of an Android app/apk, ie a D shared library that's invoked by the Java runtime.
>
> [...]

Really exciting news, I'll give it a try today, your great effort is much appreciated!
July 31, 2015
On 31/07/2015 7:38 a.m., Joakim wrote:
> On Monday, 25 May 2015 at 20:08:48 UTC, Joakim wrote:
>> On Monday, 18 May 2015 at 15:47:07 UTC, Joakim wrote:
>>> Sure, have fun with your new devices. :) Hopefully, I'll get
>>> Android/ARM working before then, but I don't and won't have any
>>> AArch64 devices to test.  Not that it matters, as 64-bit ARM has even
>>> less share than x86 right now.
>>
>> Earlier this week, I stumbled across a way to get TLS working with ldc
>> for Android/ARM, similar to the approach used for Android/x86 so far.
>> Exception-handling on ARM for ldc is currently unfinished
>> (https://github.com/ldc-developers/ldc/issues/489), so if I disable a
>> handful of tests related to that, I get 36 of 42 druntime modules'
>> unit tests and around 31 of 70 phobos modules' unit tests to pass.
>> All tests were run from the command line on my Android tablet.  It
>> appears there are issues related to unicode and the GC causing many of
>> the remaining failures.
>
> Some good news, I've made progress on the port to Android/ARM, using
> ldc's 2.067 branch.  Currently, all 46 modules in druntime and 85 of 88
> modules in phobos pass their tests (I had to comment out a few tests
> across four modules) when run on the command-line.  There is a GC issue
> that causes 2-3 other modules to hang only when the tests are run as
> part of an Android app/apk, ie a D shared library that's invoked by the
> Java runtime.
>
> I've compiled an Android/ARM app that will run the remaining majority of
> tests on Android 5 Lollipop or newer, which you can download and try out
> on your Android 5 devices:
>
> https://github.com/joakim-noah/android/releases/tag/apk
>
> All tests run on my Android 5.1 device, while the last two modules
> tested by this app hang on an Android 5.0 device I tested.  All patches
> used are linked from the above release.

So how far off are we in having a D Android stack?
With full redistribution support on dlang.org.