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.

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.

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.

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.

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.

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.

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

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.

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