www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Ehem, ARM

reply "Chris" <wendlec tcd.ie> writes:
I know, I know, this question has been asked many times before. 
But it came up in a meeting the other day: is there any work 
being done on making D an ARM citizen so that _non-trivial_ D 
code can be ported to smartphones and the like? If so, what it 
the rough time frame?
Nov 14 2013
next sibling parent "eles" <eles eles.com> writes:
On Thursday, 14 November 2013 at 14:47:47 UTC, Chris wrote:
 I know, I know, this question has been asked many times before. 
 But it came up in a meeting the other day: is there any work 
 being done on making D an ARM citizen so that _non-trivial_ D 
 code can be ported to smartphones and the like? If so, what it 
 the rough time frame?

A D.arm or D.ports group?
Nov 14 2013
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Thursday, 14 November 2013 at 15:31:25 UTC, eles wrote:
 On Thursday, 14 November 2013 at 14:47:47 UTC, Chris wrote:
 I know, I know, this question has been asked many times 
 before. But it came up in a meeting the other day: is there 
 any work being done on making D an ARM citizen so that 
 _non-trivial_ D code can be ported to smartphones and the 
 like? If so, what it the rough time frame?

A D.arm or D.ports group?

Yes. Mobile devices cannot be ignored.
Nov 14 2013
prev sibling next sibling parent reply "Kai Nacke" <kai redstar.de> writes:
On Thursday, 14 November 2013 at 14:47:47 UTC, Chris wrote:
 I know, I know, this question has been asked many times before. 
 But it came up in a meeting the other day: is there any work 
 being done on making D an ARM citizen so that _non-trivial_ D 
 code can be ported to smartphones and the like? If so, what it 
 the rough time frame?

Hi Chris! LDC can generate binaries for ARM but still has a major bug which prevents working exception handling. My new developer board arrived this week so I hope to solve this issue soon. But this is only half of the story. My target is Linux/ARM which is already supported by druntime/phobos. If you target a smartphone then you also have to add Android or iOS support to druntime/phobos. I don't know if somebody is working on this topic. Regards, Kai
Nov 14 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-14 17:21, Chris wrote:

 Thanks for your reply, Kai. That's good news, however iOS and Android
 support is crucial. I hope D can soon be ported to ARM, it's just too
 important.

If you want to do anything useful on iOS you need to use Objective-C libraries, for that you bascilly need this: http://michelf.ca/projects/d-objc/ Latest update, but still quite outdated: https://github.com/jacob-carlborg/dmd/tree/d-objc -- /Jacob Carlborg
Nov 14 2013
next sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-11-14 19:14:03 +0000, Jacob Carlborg <doob me.com> said:

 On 2013-11-14 17:21, Chris wrote:
 
 Thanks for your reply, Kai. That's good news, however iOS and Android
 support is crucial. I hope D can soon be ported to ARM, it's just too
 important.

If you want to do anything useful on iOS you need to use Objective-C libraries, for that you bascilly need this: http://michelf.ca/projects/d-objc/ Latest update, but still quite outdated: https://github.com/jacob-carlborg/dmd/tree/d-objc

Still no modern runtime support I'd guess? With support only for the legacy runtime you're stuck compiling for 32-bit OS X only; 32-bit iOS uses the modern runtime. And since the DMD backend won't emit ARM code, if I were still working on this the first thing I'd do is rebase everything to work on top of LDC. Once upon a time, I did port a D game to iOS. I translated it to C++. But the amount of Objective-C code was pretty minimal at the end. If I had an ARM-capable D compiler at that time, even with no Objective-C support, I could have lived happily with D. http://michelf.ca/projects/tumiki-fighters/ -- Michel Fortin michel.fortin michelf.ca http://michelf.ca
Nov 14 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-15 02:50, Michel Fortin wrote:

 Still no modern runtime support I'd guess? With support only for the
 legacy runtime you're stuck compiling for 32-bit OS X only; 32-bit iOS
 uses the modern runtime.

Right, I forgot about that. I haven't done a single thing on this since the last time I announced it.
 And since the DMD backend won't emit ARM code, if I were still working
 on this the first thing I'd do is rebase everything to work on top of LDC.

I think that would be quite difficult. Although it would probably be easier to get 64bit and modern runtime support. An advantage of doing it in DMD (except that it's already in DMD) is that it's probably a bigger chance of it being officially added to D and not just an extension to LDD. If it's added to DMD it will automatically be merged by both LDC and GDC. Another idea would be to add it to DMD with the current platform support. Then when it's merged with LDC, let them add support for ARM, 64bit and modern runtime. BTW, do you automatically scan the newsgroups for "http://michelf.ca/projects/d-objc/" :) -- /Jacob Carlborg
Nov 14 2013
parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-11-15 07:33:40 +0000, Jacob Carlborg <doob me.com> said:

 On 2013-11-15 02:50, Michel Fortin wrote:
 
 And since the DMD backend won't emit ARM code, if I were still working
 on this the first thing I'd do is rebase everything to work on top of LDC.

I think that would be quite difficult. Although it would probably be easier to get 64bit and modern runtime support. An advantage of doing it in DMD (except that it's already in DMD) is that it's probably a bigger chance of it being officially added to D and not just an extension to LDD. If it's added to DMD it will automatically be merged by both LDC and GDC.

That was my idea too initially: put it in the reference implementation and other implementations will follow, and it'll become part of the language. That'd be great. But it's hard when you have to fix the backend to emit what you need. I have some fears about that for the exception handling stuff in the modern runtime, perhaps they're unjustified.
 Another idea would be to add it to DMD with the current platform 
 support. Then when it's merged with LDC, let them add support for ARM, 
 64bit and modern runtime.

I wonder if Walter will approve the merge, despite his stated intention to do so eventually. The surface area of that patch is huge, it'll take him many hours for an initial review, and probably several iterations of that review process will be required to get it to pass. I remember my smaller-scale pull request #3 that never got reviewed... but maybe (hopefully?) things have changed since then.
 BTW, do you automatically scan the newsgroups for 
 "http://michelf.ca/projects/d-objc/" :)

Haha. No. I skim by topic of interest. But I generally play the passive observer. Replying generally brings other replies, begging for more followup. I have a couple of replies that were written but which I never posted because I anticipated writing the eventual followups wouldn't be worth my time. It doesn't help that I tend to spend too much time carefully writing anything too, proofreading and weighing every word. But if you're talking about one of my projects there's more chance I'll pop in the conversation. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca
Nov 15 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-11-15 13:41, Michel Fortin wrote:

 That was my idea too initially: put it in the reference implementation
 and other implementations will follow, and it'll become part of the
 language. That'd be great. But it's hard when you have to fix the
 backend to emit what you need. I have some fears about that for the
 exception handling stuff in the modern runtime, perhaps they're
 unjustified.

Yeah, that's the biggest advantage of doing it in LDC. They already have the correct back end parts in place.
 I wonder if Walter will approve the merge, despite his stated intention
 to do so eventually. The surface area of that patch is huge, it'll take
 him many hours for an initial review, and probably several iterations of
 that review process will be required to get it to pass. I remember my
 smaller-scale pull request #3 that never got reviewed... but maybe
 (hopefully?) things have changed since then.

Hopefully things are better now. There seems to be more people now that have a greater knowledge of DMD.
 Haha. No. I skim by topic of interest. But I generally play the passive
 observer. Replying generally brings other replies, begging for more
 followup. I have a couple of replies that were written but which I never
 posted because I anticipated writing the eventual followups wouldn't be
 worth my time. It doesn't help that I tend to spend too much time
 carefully writing anything too, proofreading and weighing every word.

Understandable. Like my post about AST macros. It's always a hot topic.
 But if you're talking about one of my projects there's more chance I'll
 pop in the conversation.

-- /Jacob Carlborg
Nov 15 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-15 00:35, Manu wrote:

 Very good point. I wonder if there's room to make a push for this in 2.065.

Highly unlikely. It seems like Walter wanted us to first implement ARC, to not be worse the Objective-C currently is. But we haven't been able to come to an agreement on how to do that. As Michel noted it currently only supports 32bit and the legacy runtime. Although I think it still would be usable to include, even without ARC and 64bit/modern runtime. It will just get harder to keep up to date the longer time it takes. http://forum.dlang.org/thread/kq7li9$2j9v$1 digitalmars.com?page=4#post-kqcm79:241eqf:241:40digitalmars.com http://forum.dlang.org/thread/l34lei$255v$1 digitalmars.com -- /Jacob Carlborg
Nov 14 2013
parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-11-15 07:26:56 +0000, Jacob Carlborg <doob me.com> said:

 On 2013-11-15 00:35, Manu wrote:
 
 Very good point. I wonder if there's room to make a push for this in 2.065.

Highly unlikely. It seems like Walter wanted us to first implement ARC, to not be worse the Objective-C currently is. But we haven't been able to come to an agreement on how to do that.

Honestly, what I'd do is implement ARC for Objective-C types in the compiler without waiting for Walter to decide on anything. There's almost nothing to decide when it comes to how D/Objective-C does it: you have to do it the same way as clang. And you can't reuse anything Walter will come with without much tinkering because Objective-C ARC has to manage autoreleased objects. On the other hand once you have implemented Objective-C ARC it should be easy to retrofit the mechanics of it to other parts of D. I find it funny how I though about implementing ARC for D/Objective-C even before clang came with it. Another idea involved making the D GC capable of tracking pointers to external blocks of memory (Objective-C objects in this case) and making it call a release function when no longer referenced by D code. Some remnants of that: https://github.com/michelf/druntime/blob/d-objc/src/objc/dobjc.d#L159 -- Michel Fortin michel.fortin michelf.ca http://michelf.ca
Nov 15 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-15 13:42, Michel Fortin wrote:

 Honestly, what I'd do is implement ARC for Objective-C types in the
 compiler without waiting for Walter to decide on anything. There's
 almost nothing to decide when it comes to how D/Objective-C does it: you
 have to do it the same way as clang. And you can't reuse anything Walter
 will come with without much tinkering because Objective-C ARC has to
 manage autoreleased objects. On the other hand once you have implemented
 Objective-C ARC it should be easy to retrofit the mechanics of it to
 other parts of D.

The question is if this is something that Walter would accept to be included. -- /Jacob Carlborg
Nov 15 2013
parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-11-15 12:53:18 +0000, Jacob Carlborg <doob me.com> said:

 On 2013-11-15 13:42, Michel Fortin wrote:
 
 Honestly, what I'd do is implement ARC for Objective-C types in the
 compiler without waiting for Walter to decide on anything. There's
 almost nothing to decide when it comes to how D/Objective-C does it: you
 have to do it the same way as clang. And you can't reuse anything Walter
 will come with without much tinkering because Objective-C ARC has to
 manage autoreleased objects. On the other hand once you have implemented
 Objective-C ARC it should be easy to retrofit the mechanics of it to
 other parts of D.

The question is if this is something that Walter would accept to be included.

You mean if Walter would accept D/Objective-C without ARC? No idea. Ask him, or submit a pull request just to gauge the reaction. People have been manually managing memory with retain/release/autorelease for more than a decade and it worked pretty well, much better than any other manual reference counting scheme out there. One problem with introducing ARC later is that you'll need a compiler flag to disable or enable ARC to support both legacy and new code. Personally, I'd be more bothered by the lack of 64-bit than the lack of ARC, but that might be just because I'm good with retain/release/autorelease. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca
Nov 15 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-15 14:38, Michel Fortin wrote:

 You mean if Walter would accept D/Objective-C without ARC? No idea. Ask
 him, or submit a pull request just to gauge the reaction.

No, I was referring to just implementing ARC like it's done in Objective-C.
 People have been manually managing memory with
 retain/release/autorelease for more than a decade and it worked pretty
 well, much better than any other manual reference counting scheme out
 there. One problem with introducing ARC later is that you'll need a
 compiler flag to disable or enable ARC to support both legacy and new code.

That's true.
 Personally, I'd be more bothered by the lack of 64-bit than the lack of
 ARC, but that might be just because I'm good with
 retain/release/autorelease.

Both are important. Although, I personally don't have a need for 64bit, but it's nice to have the modern runtime. -- /Jacob Carlborg
Nov 15 2013
parent Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-11-15 14:02:20 +0000, Jacob Carlborg <doob me.com> said:

 On 2013-11-15 14:38, Michel Fortin wrote:
 
 You mean if Walter would accept D/Objective-C without ARC? No idea. Ask
 him, or submit a pull request just to gauge the reaction.

No, I was referring to just implementing ARC like it's done in Objective-C.

I honestly don't think it can work much differently. You call retain and release at the right places. Extending it to other D types is just a matter of calling a different functions depending on the type. Objective-C has a couple of special cases for pointers to autoreleased objects, but that's just a couple more rules to add, and those should be kept specific to Objective-C types. Weak pointers are a more difficult topic, but a separate one I'd say. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca
Nov 15 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-11-15 00:35, Manu wrote:

 Very good point. I wonder if there's room to make a push for this in 2.065.

Note, I'm willing work on to syncing my branches to upstream if Walter is interested in this. Getting support for 64bit and modern runtime would be too far away for this release. -- /Jacob Carlborg
Nov 15 2013
prev sibling parent reply Martin Nowak <code dawg.eu> writes:
On 11/14/2013 05:14 PM, Kai Nacke wrote:
 But this is only half of the story. My target is Linux/ARM which is
 already supported by druntime/phobos. If you target a smartphone then
 you also have to add Android or iOS support to druntime/phobos.

Currently version (linux) in druntime is equivalent to glibc. Porting druntime to bionic or newlib might be quite an effort but I have no concrete idea what issues to expect.
Nov 14 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-11-15 10:45, Paulo Pinto wrote:

 As far as I know dmd does not support cross compiling.

Only for 32bit/64bit on the same architecture. -- /Jacob Carlborg
Nov 15 2013
prev sibling next sibling parent Martin Nowak <code dawg.eu> writes:
On 11/16/2013 06:51 PM, Andrew wrote:
 I think the error was something to do with fibres in Phobos and druntime.

Fibers probably won't work out of the box, but they aren't used anywhere in druntime/phobos so did you get a hello world to run?
Nov 16 2013
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 01.12.2013 14:30, Joakim wrote:
 //test.d
 import core.stdc.stdio;

 extern (C) int main() { fputs("doing this for real?", stderr); return 0;}

 It doesn't link on Win32, Win64, or Android.  It works on linux and
 FreeBSD.  Here's the output on platforms where it doesn't work:

The reason this does not work on Win32/Win64 comes from declaring main as "extern(C)", which declares "main" for the C runtime. This prevents adding an implicite include directive to add the phobos library to the link. This happens only for D's main. So, you should either drop the "extern(C)" or add phobos.lib to the command line. If including the library is not an option, you'll have to repeat the respective declarations in your source. Just adding core.stdc.stdio to the command line might also work.
Dec 02 2013
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 02.12.2013 10:36, Joakim wrote:
 On Monday, 2 December 2013 at 08:25:39 UTC, Rainer Schuetze wrote:
 On 01.12.2013 14:30, Joakim wrote:
 //test.d
 import core.stdc.stdio;

 extern (C) int main() { fputs("doing this for real?", stderr); return
 0;}

 It doesn't link on Win32, Win64, or Android.  It works on linux and
 FreeBSD.  Here's the output on platforms where it doesn't work:

The reason this does not work on Win32/Win64 comes from declaring main as "extern(C)", which declares "main" for the C runtime. This prevents adding an implicite include directive to add the phobos library to the link. This happens only for D's main.

main fixes the linking problem on Win32/Win64. That makes sense that druntime/phobos wasn't added to the link, as the symbols _were_ added by the above stdio.d for Android. Where is this "implicit include directive?" It's confusing because "dmd -v" shows the exact same linker command being run whether that "extern (C)" is there before main or not.

The compiler embeds it into the object file if code for "D main" is generated. The respective code is around line 742, glue.c.
 So, you should either drop the "extern(C)" or add phobos.lib to the
 command line.

 If including the library is not an option, you'll have to repeat the
 respective declarations in your source. Just adding core.stdc.stdio to
 the command line might also work.

the ported core.stdc druntime object files for Android into a libphobos2.a, as that library name is hardcoded into dmd. Perhaps that was a mistake, I'll look further into why it doesn't link.

IIRC it is not possible to embed a linker directive into an ELF object file, so it must always be specified on the command line. Maybe the linker is looking for libphobos2.a in the wrong directories? You can change the name of the runtime library with -defaultlib.
Dec 02 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-12-28 23:21, Joakim wrote:

 I haven't completely grasped TLS and how it's done on OS X yet, but I
 get the sense I'll have to modify dmd a little to get TLS working with
 bionic.  It appears that Martin and Johannes have looked into this
 before, so if you two have any feedback, let me know.

Yes, you need to modify dmd. On Mac OS X every time a TLS variable is accessed the compiler inserts a call to ___tls_get_addr which is declared in rt.sections_osx in druntime. -- /Jacob Carlborg
Dec 29 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 23/04/14 13:39, Joakim wrote:

 Alright, finally hacked dmd to produce something like packed TLS for
 ELF.  I just ran the druntime unit tests on Android/x86 and all 38
 modules passed, :) even after changing the number of TLS variables a
 couple times, which was causing segfaults with the native TLS before.
 I'll try running the phobos unit tests next, then building a sample
 Android/x86 D app/apk, ie the kind you can actually install on Android.

That's awesome :) -- /Jacob Carlborg
Apr 23 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Thursday, 14 November 2013 at 16:14:16 UTC, Kai Nacke wrote:
 On Thursday, 14 November 2013 at 14:47:47 UTC, Chris wrote:
 I know, I know, this question has been asked many times 
 before. But it came up in a meeting the other day: is there 
 any work being done on making D an ARM citizen so that 
 _non-trivial_ D code can be ported to smartphones and the 
 like? If so, what it the rough time frame?

Hi Chris! LDC can generate binaries for ARM but still has a major bug which prevents working exception handling. My new developer board arrived this week so I hope to solve this issue soon. But this is only half of the story. My target is Linux/ARM which is already supported by druntime/phobos. If you target a smartphone then you also have to add Android or iOS support to druntime/phobos. I don't know if somebody is working on this topic. Regards, Kai

Thanks for your reply, Kai. That's good news, however iOS and Android support is crucial. I hope D can soon be ported to ARM, it's just too important.
Nov 14 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--089e013a2ac8aea7ad04eb2b8971
Content-Type: text/plain; charset=UTF-8

On 15 November 2013 05:14, Jacob Carlborg <doob me.com> wrote:

 On 2013-11-14 17:21, Chris wrote:

  Thanks for your reply, Kai. That's good news, however iOS and Android
 support is crucial. I hope D can soon be ported to ARM, it's just too
 important.

If you want to do anything useful on iOS you need to use Objective-C libraries, for that you bascilly need this: http://michelf.ca/projects/d-objc/ Latest update, but still quite outdated: https://github.com/jacob- carlborg/dmd/tree/d-objc

Very good point. I wonder if there's room to make a push for this in 2.065. --089e013a2ac8aea7ad04eb2b8971 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 15 November 2013 05:14, Jacob Carlborg <span dir=3D"ltr= ">&lt;<a href=3D"mailto:doob me.com" target=3D"_blank">doob me.com</a>&gt;<= /span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo= ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c= cc solid;padding-left:1ex"> <div class=3D"im">On 2013-11-14 17:21, Chris wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Thanks for your reply, Kai. That&#39;s good news, however iOS and Android<b= r> support is crucial. I hope D can soon be ported to ARM, it&#39;s just too<b= r> important.<br> </blockquote> <br></div> If you want to do anything useful on iOS you need to use Objective-C librar= ies, for that you bascilly need this:<br> <br> <a href=3D"http://michelf.ca/projects/d-objc/" target=3D"_blank">http://mic= helf.ca/projects/d-<u></u>objc/</a><br> <br> Latest update, but still quite outdated: <a href=3D"https://github.com/jaco= b-carlborg/dmd/tree/d-objc" target=3D"_blank">https://github.com/jacob-<u><= /u>carlborg/dmd/tree/d-objc</a></blockquote><div><br></div><div>Very good p= oint. I wonder if there&#39;s room to make a push for this in 2.065.</div> </div></div></div> --089e013a2ac8aea7ad04eb2b8971--
Nov 14 2013
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
On Friday, 15 November 2013 at 00:18:50 UTC, Martin Nowak wrote:
 On 11/14/2013 05:14 PM, Kai Nacke wrote:
 But this is only half of the story. My target is Linux/ARM 
 which is
 already supported by druntime/phobos. If you target a 
 smartphone then
 you also have to add Android or iOS support to druntime/phobos.

Currently version (linux) in druntime is equivalent to glibc. Porting druntime to bionic or newlib might be quite an effort but I have no concrete idea what issues to expect.

As Kai says, has anyone worked on getting D running on Android before? I've been thinking about attempting an Android port for years. I thought I'd spin up some x86 VMs this weekend and take a crack at getting D working on Android/x86 (http://www.android-x86.org/) as a first step. If anyone has started on this already, I could chip in on their branch. Also, does dmd have any support for cross-compilation or is it better to stick to ldc/gdc when cross compiling to Android? On a related note, it looks like Rust was ported to Android/ARM earlier this year: https://github.com/mozilla/rust/wiki/Doc-building-for-android
Nov 14 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 15 November 2013 at 06:18:00 UTC, Joakim wrote:
 On Friday, 15 November 2013 at 00:18:50 UTC, Martin Nowak wrote:
 On 11/14/2013 05:14 PM, Kai Nacke wrote:
 But this is only half of the story. My target is Linux/ARM 
 which is
 already supported by druntime/phobos. If you target a 
 smartphone then
 you also have to add Android or iOS support to 
 druntime/phobos.

Currently version (linux) in druntime is equivalent to glibc. Porting druntime to bionic or newlib might be quite an effort but I have no concrete idea what issues to expect.

As Kai says, has anyone worked on getting D running on Android before? I've been thinking about attempting an Android port for years. I thought I'd spin up some x86 VMs this weekend and take a crack at getting D working on Android/x86 (http://www.android-x86.org/) as a first step. If anyone has started on this already, I could chip in on their branch. Also, does dmd have any support for cross-compilation or is it better to stick to ldc/gdc when cross compiling to Android? On a related note, it looks like Rust was ported to Android/ARM earlier this year: https://github.com/mozilla/rust/wiki/Doc-building-for-android

Yes, have a look at an initial port of GDC to Android https://bitbucket.org/goshawk/gdc/wiki/GDC%20on%20Android
Nov 14 2013
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
On Friday, 15 November 2013 at 07:22:07 UTC, Paulo Pinto wrote:
 On Friday, 15 November 2013 at 06:18:00 UTC, Joakim wrote:
 As Kai says, has anyone worked on getting D running on Android 
 before?  I've been thinking about attempting an Android port 
 for years.  I thought I'd spin up some x86 VMs this weekend 
 and take a crack at getting D working on Android/x86 
 (http://www.android-x86.org/) as a first step.  If anyone has 
 started on this already, I could chip in on their branch.

Yes, have a look at an initial port of GDC to Android https://bitbucket.org/goshawk/gdc/wiki/GDC%20on%20Android

Thanks for the link. It looks like Johannes Pfau took a stab at getting some minimal Android support into gdc a couple years back, with the handful of small patches listed here: https://bitbucket.org/jpf/gdc/branch/android Anyone get any farther than that? Would it make sense to use dmd for linux/x86 to cross-compile to Android/x86 or is this a job for ldc/gdc only?
Nov 15 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 15 November 2013 at 08:24:55 UTC, Joakim wrote:
 On Friday, 15 November 2013 at 07:22:07 UTC, Paulo Pinto wrote:
 On Friday, 15 November 2013 at 06:18:00 UTC, Joakim wrote:
 As Kai says, has anyone worked on getting D running on 
 Android before?  I've been thinking about attempting an 
 Android port for years.  I thought I'd spin up some x86 VMs 
 this weekend and take a crack at getting D working on 
 Android/x86 (http://www.android-x86.org/) as a first step.  
 If anyone has started on this already, I could chip in on 
 their branch.

Yes, have a look at an initial port of GDC to Android https://bitbucket.org/goshawk/gdc/wiki/GDC%20on%20Android

Thanks for the link. It looks like Johannes Pfau took a stab at getting some minimal Android support into gdc a couple years back, with the handful of small patches listed here: https://bitbucket.org/jpf/gdc/branch/android Anyone get any farther than that? Would it make sense to use dmd for linux/x86 to cross-compile to Android/x86 or is this a job for ldc/gdc only?

I would say ldc/gdc only, as LLVM/gcc are the supported NDK toolchains and dmd lacks an ARM backend.
Nov 15 2013
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
On Friday, 15 November 2013 at 08:54:21 UTC, Paulo Pinto wrote:
 On Friday, 15 November 2013 at 08:24:55 UTC, Joakim wrote:
 Would it make sense to use dmd for linux/x86 to cross-compile 
 to Android/x86 or is this a job for ldc/gdc only?

I would say ldc/gdc only, as LLVM/gcc are the supported NDK toolchains and dmd lacks an ARM backend.

Yeah, I'm aware of these facts, but I don't think they matter. For one, dmd not having an ARM backend doesn't impact me since I'm targeting Android/x86 for now, :) as stated earlier. I don't think it's relevant what toolchains are integrated into the NDK as, for example, the Free Pascal compiler can now compile to Android and it isn't based on gcc or llvm: http://wiki.freepascal.org/Android I think the bigger issue is that llvm/gcc and therefore ldc/gdc have support for cross-compilation, but I don't know the status of cross-compiling support with dmd.
Nov 15 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 15 November 2013 at 09:20:18 UTC, Joakim wrote:
 On Friday, 15 November 2013 at 08:54:21 UTC, Paulo Pinto wrote:
 On Friday, 15 November 2013 at 08:24:55 UTC, Joakim wrote:
 Would it make sense to use dmd for linux/x86 to cross-compile 
 to Android/x86 or is this a job for ldc/gdc only?

I would say ldc/gdc only, as LLVM/gcc are the supported NDK toolchains and dmd lacks an ARM backend.

Yeah, I'm aware of these facts, but I don't think they matter. For one, dmd not having an ARM backend doesn't impact me since I'm targeting Android/x86 for now, :) as stated earlier. I don't think it's relevant what toolchains are integrated into the NDK as, for example, the Free Pascal compiler can now compile to Android and it isn't based on gcc or llvm: http://wiki.freepascal.org/Android I think the bigger issue is that llvm/gcc and therefore ldc/gdc have support for cross-compilation, but I don't know the status of cross-compiling support with dmd.

Yes, but FreePascal already had an ARM backend before they started with Android, and cross-compiling support infrastructure. As far as I know dmd does not support cross compiling. -- Paulo
Nov 15 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--047d7bdc9d78c12c5604eb345164
Content-Type: text/plain; charset=ISO-8859-1

On 15 November 2013 09:45, Paulo Pinto <pjmlp progtools.org> wrote:

 On Friday, 15 November 2013 at 09:20:18 UTC, Joakim wrote:

 On Friday, 15 November 2013 at 08:54:21 UTC, Paulo Pinto wrote:

 On Friday, 15 November 2013 at 08:24:55 UTC, Joakim wrote:

 Would it make sense to use dmd for linux/x86 to cross-compile to
 Android/x86 or is this a job for ldc/gdc only?

I would say ldc/gdc only, as LLVM/gcc are the supported NDK toolchains and dmd lacks an ARM backend.

Yeah, I'm aware of these facts, but I don't think they matter. For one, dmd not having an ARM backend doesn't impact me since I'm targeting Android/x86 for now, :) as stated earlier. I don't think it's relevant what toolchains are integrated into the NDK as, for example, the Free Pascal compiler can now compile to Android and it isn't based on gcc or llvm: http://wiki.freepascal.org/Android I think the bigger issue is that llvm/gcc and therefore ldc/gdc have support for cross-compilation, but I don't know the status of cross-compiling support with dmd.

Yes, but FreePascal already had an ARM backend before they started with Android, and cross-compiling support infrastructure. As far as I know dmd does not support cross compiling. -- Paulo

-m32/-m64 is the closest you'll get to a cross-compilation in dmd. ;-) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --047d7bdc9d78c12c5604eb345164 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= 5 November 2013 09:45, Paulo Pinto <span dir=3D"ltr">&lt;<a href=3D"mailto:= pjmlp progtools.org" target=3D"_blank">pjmlp progtools.org</a>&gt;</span> w= rote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On F= riday, 15 November 2013 at 09:20:18 UTC, Joakim wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On Friday, 15 November 2013 at 08:54:21 UTC, Paulo Pinto wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On Friday, 15 November 2013 at 08:24:55 UTC, Joakim wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Would it make sense to use dmd for linux/x86 to cross-compile to Android/x8= 6 or is this a job for ldc/gdc only?<br> </blockquote> <br> I would say ldc/gdc only, as LLVM/gcc are the supported NDK toolchains and = dmd lacks an ARM backend.<br> </blockquote> <br> Yeah, I&#39;m aware of these facts, but I don&#39;t think they matter. =A0F= or one, dmd not having an ARM backend doesn&#39;t impact me since I&#39;m t= argeting Android/x86 for now, :) as stated earlier. =A0I don&#39;t think it= &#39;s relevant what toolchains are integrated into the NDK as, for example= , the Free Pascal compiler can now compile to Android and it isn&#39;t base= d on gcc or llvm:<br> <br> <a href=3D"http://wiki.freepascal.org/Android" target=3D"_blank">http://wik= i.freepascal.org/<u></u>Android</a><br> <br> I think the bigger issue is that llvm/gcc and therefore ldc/gdc have suppor= t for cross-compilation, but I don&#39;t know the status of cross-compiling= support with dmd.<br> </blockquote> <br></div></div> Yes, but FreePascal already had an ARM backend before they started with And= roid, and cross-compiling support infrastructure.<br> <br> As far as I know dmd does not support cross compiling.<br> <br> --<br> Paulo<br> </blockquote></div><br><br></div><div class=3D"gmail_extra">-m32/-m64 is th= e closest you&#39;ll get to a cross-compilation in dmd. ;-)<br clear=3D"all= "></div><div class=3D"gmail_extra"><br>-- <br>Iain Buclaw<br><br>*(p &lt; e= ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;; </div></div> --047d7bdc9d78c12c5604eb345164--
Nov 15 2013
prev sibling next sibling parent "Elvis Zhou" <elvis.x.zhou gmail.com> writes:
On Friday, 15 November 2013 at 06:18:00 UTC, Joakim wrote:
 On Friday, 15 November 2013 at 00:18:50 UTC, Martin Nowak wrote:
 On 11/14/2013 05:14 PM, Kai Nacke wrote:
 But this is only half of the story. My target is Linux/ARM 
 which is
 already supported by druntime/phobos. If you target a 
 smartphone then
 you also have to add Android or iOS support to 
 druntime/phobos.

Currently version (linux) in druntime is equivalent to glibc. Porting druntime to bionic or newlib might be quite an effort but I have no concrete idea what issues to expect.

As Kai says, has anyone worked on getting D running on Android before? I've been thinking about attempting an Android port for years. I thought I'd spin up some x86 VMs this weekend and take a crack at getting D working on Android/x86 (http://www.android-x86.org/) as a first step. If anyone has started on this already, I could chip in on their branch. Also, does dmd have any support for cross-compilation or is it better to stick to ldc/gdc when cross compiling to Android? On a related note, it looks like Rust was ported to Android/ARM earlier this year: https://github.com/mozilla/rust/wiki/Doc-building-for-android

A month ago I tried to cross compile a Hello World for Android with ldc on Debian7 x64 with android_ndk_r9 but failed with lots of link errors. One of those issues reveal that qsort is absent from Android stdlib, I get over it by grabbing a qsort.c and it works. Other issues are beyond my knowledge and I'm too busy to continue, hope I can take some time to hack on this late this month.
Nov 15 2013
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
On Friday, 15 November 2013 at 09:45:42 UTC, Paulo Pinto wrote:
 As far as I know dmd does not support cross compiling.

to new platforms and I found the following: * Linux Version * ------------- * There are two main issues: hosting the compiler on linux, * and generating (targetting) linux executables. * The "linux" and "__GNUC__" macros control hosting issues * for operating system and compiler dependencies, respectively. * To target linux executables, use ELFOBJ for things specific to the * ELF object file format, and TARGET_LINUX for things specific to * the linux memory model. * If this is all done right, one could generate a linux object file * even when compiling on win32, and vice versa. * The compiler source code currently uses these macros very inconsistently * with these goals, and should be fixed. https://github.com/D-Programming-Language/dmd/blob/master/src/backend/cdef.h#L71 So it appears that the dmd backend has some support for cross-compiling, although likely incomplete.
Nov 15 2013
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
Thanks for all your answers. I see that it's still a big big 
issue. I believe we really have to push this, because ARM support 
is vital. If we want people to use D, there will have to be a 
port to ARM, else it will put people off. The code I've been 
working on runs fine on Windows/Mac/Linux. But users will ask for 
effin iPhone or Android support. Everyone wants it and if D can't 
cater for it ...
Nov 15 2013
prev sibling next sibling parent "Martin Nowak" <code dawg.eu> writes:
On Friday, 15 November 2013 at 09:20:18 UTC, Joakim wrote:
 For one, dmd not having an ARM backend doesn't impact me since 
 I'm targeting Android/x86 for now, :) as stated earlier.

Interesting, then you'll mostly focus on druntime and glibc vs. bionic issues. The linux/ELF support of dmd should mostly work.
Nov 15 2013
prev sibling next sibling parent "Martin Nowak" <code dawg.eu> writes:
On Friday, 15 November 2013 at 11:46:29 UTC, Chris wrote:
 I see that it's still a big big issue.

 I believe we really have to push this, because ARM support is 
 vital.

this...
Nov 15 2013
prev sibling next sibling parent "Kai Nacke" <kai redstar.de> writes:
On Friday, 15 November 2013 at 11:18:06 UTC, Joakim wrote:
 On Friday, 15 November 2013 at 09:45:42 UTC, Paulo Pinto wrote:
 As far as I know dmd does not support cross compiling.

to new platforms and I found the following: * Linux Version * ------------- * There are two main issues: hosting the compiler on linux, * and generating (targetting) linux executables. * The "linux" and "__GNUC__" macros control hosting issues * for operating system and compiler dependencies, respectively. * To target linux executables, use ELFOBJ for things specific to the * ELF object file format, and TARGET_LINUX for things specific to * the linux memory model. * If this is all done right, one could generate a linux object file * even when compiling on win32, and vice versa. * The compiler source code currently uses these macros very inconsistently * with these goals, and should be fixed. https://github.com/D-Programming-Language/dmd/blob/master/src/backend/cdef.h#L71 So it appears that the dmd backend has some support for cross-compiling, although likely incomplete.

Hi Joakim! Yes, there is a some support, but not too much. The existence of the TARGET_* macros means that you can't have one compiler with 2 or more platform targets. But there should be no real problem to create a dmd executable on Linux/ARM producing object files for Windows/x86. (Well - no problem except for the real data type. :-) ) But who needs that kind of cross-compiling? To be useful for producing ARM binaries, you need an ARM backend. This is already available for LDC and GDC. IMHO it is easier to pick one of those compilers and think about and create a cross-compiling environment instead of starting by zero. (For LDC, this is issue #490: https://github.com/ldc-developers/ldc/issues/490) Regards, Kai
Nov 15 2013
prev sibling next sibling parent "Martin Nowak" <code dawg.eu> writes:
Bionic even got 
[dl_iterate_phdr](https://github.com/android/platform_bionic/commit/24053a461e7a20f34002
62c1bb122023134989) 
which we need for shared library support.
Write me a mail if you hit any druntime issues during the port.
Nov 15 2013
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
On Friday, 15 November 2013 at 12:07:19 UTC, Martin Nowak wrote:
 On Friday, 15 November 2013 at 09:20:18 UTC, Joakim wrote:
 For one, dmd not having an ARM backend doesn't impact me since 
 I'm targeting Android/x86 for now, :) as stated earlier.

Interesting, then you'll mostly focus on druntime and glibc vs. bionic issues. The linux/ELF support of dmd should mostly work.

Yes, I thought that would be easier, to split the effort into two parts. First, get D working on Android/x86, then, linux/ARM. Some fine day, we combine the two into Android/ARM. :) On Friday, 15 November 2013 at 12:18:20 UTC, Kai Nacke wrote:
 Hi Joakim!

 Yes, there is a some support, but not too much. The existence 
 of the TARGET_* macros means that you can't have one compiler 
 with 2 or more platform targets.

I think what I'll try initially is to hack the linux target on dmd to produce an Android/ELF/x86 executable, by tying into the Android NDK and linker. That might be the shortest path to something that works.
 But there should be no real problem to create a dmd executable 
 on Linux/ARM producing object files for Windows/x86. (Well - no 
 problem except for the real data type. :-) ) But who needs that 
 kind of cross-compiling?

Maybe not linux/ARM, but if D ever takes off, I could see it being convenient someday to cross-compile Windows/x64 executables on linux/x64 servers, perhaps by tying into Wine. I have compiled a small Windows utility using dmd under Wine on a FreeBSD host before: it worked. :) You wouldn't need to license Windows for a bunch of build servers and could cut costs that way. Obviously not a concern today, but we should get cross-compiling working as much as possible and cross-compiling to Android might be a good first step. Hell, by then, linux/ARM might be prevalent in the data center. ;)
 To be useful for producing ARM binaries, you need an ARM 
 backend. This is already available for LDC and GDC. IMHO it is 
 easier to pick one of those compilers and think about and 
 create a cross-compiling environment instead of starting by 
 zero. (For LDC, this is issue #490: 
 https://github.com/ldc-developers/ldc/issues/490)

I'm only focusing on Android/x86 for now: why does everyone keep bringing up ARM? It's almost as though Android/x86 gets translated into Android/ARM in their head. ;) Perhaps it is easier to cross-compile with ldc/gdc, or perhaps the overall port will be harder because I have to then dive into those larger llvm/gcc codebases, whereas the dmd backend looks simpler to me, at least so far. I'll give it a whirl with dmd first and then move to ldc if I get stuck. Thanks for the advice, I may end up following it.
Nov 15 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--001a11c2c1ae2b41c404eb3b95c6
Content-Type: text/plain; charset=ISO-8859-1

On 15 November 2013 18:40, Joakim <joakim airpost.net> wrote:

 On Friday, 15 November 2013 at 12:07:19 UTC, Martin Nowak wrote:

 On Friday, 15 November 2013 at 09:20:18 UTC, Joakim wrote:

 For one, dmd not having an ARM backend doesn't impact me since I'm
 targeting Android/x86 for now, :) as stated earlier.

Interesting, then you'll mostly focus on druntime and glibc vs. bionic issues. The linux/ELF support of dmd should mostly work.

Yes, I thought that would be easier, to split the effort into two parts. First, get D working on Android/x86, then, linux/ARM. Some fine day, we combine the two into Android/ARM. :)

-- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --001a11c2c1ae2b41c404eb3b95c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= 5 November 2013 18:40, Joakim <span dir=3D"ltr">&lt;<a href=3D"mailto:joaki= m airpost.net" target=3D"_blank">joakim airpost.net</a>&gt;</span> wrote:<b= r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:= 1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On Friday, 15 November 2013 at 12:0= 7:19 UTC, Martin Nowak wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On Friday, 15 November 2013 at 09:20:18 UTC, Joakim wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> For one, dmd not having an ARM backend doesn&#39;t impact me since I&#39;m = targeting Android/x86 for now, :) as stated earlier.<br> </blockquote> <br> Interesting, then you&#39;ll mostly focus on druntime and glibc vs. bionic = issues.<br> The linux/ELF support of dmd should mostly work.<br> </blockquote> <br></div></div> Yes, I thought that would be easier, to split the effort into two parts. = =A0First, get D working on Android/x86, then, linux/ARM. =A0Some fine day, = we combine the two into Android/ARM. :)<div class=3D"im"><br></div></blockq= uote> </div><br></div><div class=3D"gmail_extra">GNU/Linux on ARM will come first= ... it&#39;s now only a matter of time. ;)<br></div><div class=3D"gmail_ext= ra"><br clear=3D"all"><br>-- <br>Iain Buclaw<br><br>*(p &lt; e ? p++ : p) = =3D (c &amp; 0x0f) + &#39;0&#39;; </div></div> --001a11c2c1ae2b41c404eb3b95c6--
Nov 15 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Fri, 15 Nov 2013 09:24:53 +0100
schrieb "Joakim" <joakim airpost.net>:

 On Friday, 15 November 2013 at 07:22:07 UTC, Paulo Pinto wrote:
 On Friday, 15 November 2013 at 06:18:00 UTC, Joakim wrote:
 As Kai says, has anyone worked on getting D running on Android 
 before?  I've been thinking about attempting an Android port 
 for years.  I thought I'd spin up some x86 VMs this weekend 
 and take a crack at getting D working on Android/x86 
 (http://www.android-x86.org/) as a first step.  If anyone has 
 started on this already, I could chip in on their branch.

Yes, have a look at an initial port of GDC to Android https://bitbucket.org/goshawk/gdc/wiki/GDC%20on%20Android

Thanks for the link. It looks like Johannes Pfau took a stab at getting some minimal Android support into gdc a couple years back, with the handful of small patches listed here: https://bitbucket.org/jpf/gdc/branch/android Anyone get any farther than that? Would it make sense to use dmd for linux/x86 to cross-compile to Android/x86 or is this a job for ldc/gdc only?

There are 3 main points which need to be addressed for a solid Android port: * Druntime must be ported to bionic. Not difficult, but annoying as bionic is a mixture between bsd and posix code, so you'll have to edit many version statements. All compilers will benefit from that. * You need to implement TLS support. Last time I checked there bionic didn't support native TLS and gcc's emulated TLS doesn't work with the D GC. * The main program in Android should always be java code, native code loaded as shared libraries. This is implemented in DMD now, but not in GDC. (And IIRC not in LDC either?)
Nov 15 2013
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
On Friday, 15 November 2013 at 18:44:20 UTC, Iain Buclaw wrote:
 On 15 November 2013 18:40, Joakim <joakim airpost.net> wrote:
 Yes, I thought that would be easier, to split the effort into 
 two parts.
  First, get D working on Android/x86, then, linux/ARM.  Some 
 fine day, we
 combine the two into Android/ARM. :)

time. ;)

Everything is "only a matter of time." ;) The order is not important; it'd be great if linux/ARM is done first, though I hope gdc isn't the only one that does it. On Friday, 15 November 2013 at 19:09:24 UTC, Johannes Pfau wrote:
 There are 3 main points which need to be addressed for a solid 
 Android
 port:

 * Druntime must be ported to bionic. Not difficult, but 
 annoying as
   bionic is a mixture between bsd and posix code, so you'll 
 have to
   edit many version statements. All compilers will benefit from 
 that.

 * You need to implement TLS support. Last time I checked there 
 bionic
   didn't support native TLS and gcc's emulated TLS   doesn't 
 work with
   the D GC.

__thread keyword. I'll look into it more as I go.
 * The main program in Android should always be java code, 
 native code
   loaded as shared libraries. This is implemented in DMD now, 
 but not
   in GDC. (And IIRC not in LDC either?)

for now. Perhaps someone else will tie D into JNI and get it working with Dalvik, I'm not interested in that. Thanks for the info.
Nov 15 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--001a11c2ca5cb7a91304eb3f6ee4
Content-Type: text/plain; charset=ISO-8859-1

On 15 November 2013 21:14, Joakim <joakim airpost.net> wrote:

 On Friday, 15 November 2013 at 18:44:20 UTC, Iain Buclaw wrote:

 On 15 November 2013 18:40, Joakim <joakim airpost.net> wrote:

 Yes, I thought that would be easier, to split the effort into two parts.
  First, get D working on Android/x86, then, linux/ARM.  Some fine day, we
 combine the two into Android/ARM. :)

  GNU/Linux on ARM will come first... it's now only a matter of time. ;)


Everything is "only a matter of time." ;) The order is not important; it'd be great if linux/ARM is done first, though I hope gdc isn't the only one that does it. On Friday, 15 November 2013 at 19:09:24 UTC, Johannes Pfau wrote:
 There are 3 main points which need to be addressed for a solid Android
 port:

 * Druntime must be ported to bionic. Not difficult, but annoying as
   bionic is a mixture between bsd and posix code, so you'll have to
   edit many version statements. All compilers will benefit from that.

* You need to implement TLS support. Last time I checked there bionic
   didn't support native TLS and gcc's emulated TLS   doesn't work with
   the D GC.

keyword. I'll look into it more as I go. * The main program in Android should always be java code, native code
   loaded as shared libraries. This is implemented in DMD now, but not
   in GDC. (And IIRC not in LDC either?)

Perhaps someone else will tie D into JNI and get it working with Dalvik, I'm not interested in that.

in my head as going down this route with D (gdc) support in the same way through some sort of magic module which generates these special types (jint, jclass, etc) - not too different from eg: gcc.builtins module. But for the time being at least this is a deferred long-term wish list goal. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --001a11c2ca5cb7a91304eb3f6ee4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= 5 November 2013 21:14, Joakim <span dir=3D"ltr">&lt;<a href=3D"mailto:joaki= m airpost.net" target=3D"_blank">joakim airpost.net</a>&gt;</span> wrote:<b= r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:= 1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Friday, 15 November 2013 at 18:44:20 UTC, Iain Buclaw = wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> On 15 November 2013 18:40, Joakim &lt;<a href=3D"mailto:joakim airpost.net"= target=3D"_blank">joakim airpost.net</a>&gt; wrote:<br> </div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Yes, I thought that would be easier, to split the effort into two parts.<br=

we<br> combine the two into Android/ARM. :)<br> <br> </blockquote></div><div class=3D"im"> GNU/Linux on ARM will come first... it&#39;s now only a matter of time. ;)<= br> </div></blockquote> <br> Everything is &quot;only a matter of time.&quot; ;) The order is not import= ant; it&#39;d be great if linux/ARM is done first, though I hope gdc isn&#3= 9;t the only one that does it.<div class=3D"im"><br> <br> On Friday, 15 November 2013 at 19:09:24 UTC, Johannes Pfau wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> There are 3 main points which need to be addressed for a solid Android<br> port:<br> <br> * Druntime must be ported to bionic. Not difficult, but annoying as<br> =A0 bionic is a mixture between bsd and posix code, so you&#39;ll have to<b= r> =A0 edit many version statements. All compilers will benefit from that.<br> </blockquote></div> Yep, this is the part I&#39;m taking a stab at.<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> * You need to implement TLS support. Last time I checked there bionic<br> =A0 didn&#39;t support native TLS and gcc&#39;s emulated TLS =A0 doesn&#39;= t work with<br> =A0 the D GC.<br> </blockquote></div> I think there&#39;s TLS support in bionic now, but not with the __thread ke= yword. =A0I&#39;ll look into it more as I go.<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> * The main program in Android should always be java code, native code<br> =A0 loaded as shared libraries. This is implemented in DMD now, but not<br> =A0 in GDC. (And IIRC not in LDC either?)<br> </blockquote></div> I just want to get it working as a pure native compilation option for now. = =A0Perhaps someone else will tie D into JNI and get it working with Dalvik,= I&#39;m not interested in that.<br> <br> </blockquote></div><br></div><div class=3D"gmail_extra">C++ (as in g++) has= compiler support with JNI.=A0 I&#39;ve been turning the idea in my head as= going down this route with D (gdc) support in the same way through some so= rt of magic module which generates these special types (jint, jclass, etc) = - not too different from eg: gcc.builtins module.=A0 But for the time being= at least this is a deferred long-term wish list goal.<br> </div><div class=3D"gmail_extra"><br>-- <br>Iain Buclaw<br><br>*(p &lt; e ?= p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;; </div></div> --001a11c2ca5cb7a91304eb3f6ee4--
Nov 15 2013
prev sibling next sibling parent "Andrew" <andrew nowhere.com> writes:
A few weeks ago I tried compiling gdc and ldc on my Debian arm 
system and they built Ok but the apps crashed when run. I think 
the error was something to do with fibres in Phobos and druntime.

I tried quickly hacking in missing architecture macros for Arm 
but I didn't know what I was doing so it didn't help.

I'd start with the runtime and Phobos before looking at obj-c 
support and I'll be delighted to test it once you have it working.

There are many more arm Linux systems as well as iOS and Android 
e.g. Raspberry pi's, other SBC's like cubieboard, arduino, 
chromebooks, chromecast, kindle etc. it's estimated that 25% of 
all laptops and 10% of servers will be arm based by the end of 
next year. D will be dead unless it supports arm.

I tried valiantly to get D working and even bought the book but 
alas I've had to abandon it for now.
Nov 16 2013
prev sibling next sibling parent "Andrew" <andrew nowhere.com> writes:
On Saturday, 16 November 2013 at 18:03:29 UTC, Martin Nowak wrote:
 On 11/16/2013 06:51 PM, Andrew wrote:
 I think the error was something to do with fibres in Phobos 
 and druntime.

Fibers probably won't work out of the box, but they aren't used anywhere in druntime/phobos so did you get a hello world to run?

Hello world did run but anything that needed to allocate memory crashed.
Nov 16 2013
prev sibling next sibling parent "Andrew" <andrew nowhere.com> writes:
Just a thought but most ARM systems, Linux based, used EABI 
whereas iOS uses an Apple specific ABI so you'll probably need to 
target each separately. Also there are two variants of EABI 
hard-float (most common now) and soft-float.
Nov 16 2013
prev sibling next sibling parent "Doodoo" <barf barf.com> writes:
  1. Remove the stupid GC, it doesn't scale anyway
  2. Compile to C or C++

DONE!

WAHOOO
Nov 16 2013
prev sibling next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Friday, 15 November 2013 at 19:09:24 UTC, Johannes Pfau wrote:
 * The main program in Android should always be java code, 
 native code
   loaded as shared libraries. This is implemented in DMD now, 
 but not
   in GDC. (And IIRC not in LDC either?)

On the 2.064 frontend branch, LDC already uses the same module registration mechanism than DMD, so we are pretty close to working shared library support. There are probably two or three details that still need attention, but I don't expect any major roadblocks. All that is needed at this point is somebody spending an evening or two to iron the remaining kinks out. David
Nov 16 2013
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
On Friday, 15 November 2013 at 10:31:40 UTC, Elvis Zhou wrote:
 On Friday, 15 November 2013 at 06:18:00 UTC, Joakim wrote:
 Also, does dmd have any support for cross-compilation or is it 
 better to stick to ldc/gdc when cross compiling to Android?

A month ago I tried to cross compile a Hello World for Android with ldc on Debian7 x64 with android_ndk_r9 but failed with lots of link errors. One of those issues reveal that qsort is absent from Android stdlib, I get over it by grabbing a qsort.c and it works. Other issues are beyond my knowledge and I'm too busy to continue, hope I can take some time to hack on this late this month.

What did you modify in ldc to try and get it to work with the NDK and compile an Android-compatible binary? I spent some time setting up the appropriate VMs and looking at the relevant Android dev tools myself. It appears that the Android NDK uses a lightly patched version of stock llvm/clang 3.3, along with the gold linker. Their patches are available online: https://android.googlesource.com/toolchain/llvm/+log/release_33 https://android.googlesource.com/toolchain/clang/+log/release_33 Their llvm is the same as llvm 3.3 until commit ce33750 and clang is the same until commit 20c7d45. The stock llvm/clang 3.3 have some limited support for Android, not much. I'm going to start going through those patches next. Since there are only about 50-100 llvm/clang patches, many of them architecture-specific and so not necessary, this suggests that the Android ABI is not that different from linux. Although, when I ran ldd from Arch linux on an x86 sample app compiled by the NDK, it said "error while loading shared libraries: /usr/lib/libc.so: invalid ELF header," suggesting there is some difference. They wrote their own ldd for the NDK, which works fine with their generated code: https://android.googlesource.com/platform/ndk/+/master/sources/host-tools/ndk-depends/ndk-depends.cc Turns out I was wrong earlier when I said I'd compile D to pure native, as opposed to a shared library pulled in through JNI, as the former is not possible on Android. I saw some docs earlier where they said you can write pure native apps now and you can, but I now see that you still have to compile it to a shared library, because they want everything sandboxed within Dalvik. You provide an android_main function as the entry point from Dalvik into the native app/library, so shared library support and some JNI compatibility are necessary for D to work on Android. It appears the next steps to get D working on Android/x86 are: 1) Get a basic D "hello world" shared library to compile and run on Android, by modifying dmd to generate an Android-compatible shared library. 2) Get druntime and phobos working as much as possible. 3) Translate the remaining native Android API headers so they can be called from D. I was hoping to mostly work on 2), but it appears there's some work for 1) that has to be done first. If anybody else wants to help with 1), you too can take a look at the above llvm/clang commits and let us know what you find.
Nov 22 2013
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
On Friday, 22 November 2013 at 18:01:44 UTC, Joakim wrote:
 I spent some time setting up the appropriate VMs and looking at 
 the relevant Android dev tools myself.  It appears that the 
 Android NDK uses a lightly patched version of stock llvm/clang 
 3.3, along with the gold linker.  Their patches are available 
 online:

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

 Their llvm is the same as llvm 3.3 until commit ce33750 and 
 clang is the same until commit 20c7d45.  The stock llvm/clang 
 3.3 have some limited support for Android, not much.  I'm going 
 to start going through those patches next.

 Since there are only about 50-100 llvm/clang patches, many of 
 them architecture-specific and so not necessary, this suggests 
 that the Android ABI is not that different from linux.

there's little of significance. They hardcode two clang options for android/x86, -mstackrealign and -msse3, add a few tweaks for ARM, and that's about it. Most of the patches are for some other NDK work by MediaTek, which don't appear to be used by the official Android NDK. I was able to compile an identical stripped shared library from the samples just by using the stock clang 3.3 that's installed in Arch linux, once I added the two hardcoded flags in with the rest of the flags their makefiles generate, so you really don't even need to use their compiler, at least for Android/x86. Next step, get dmd to do the same with a "hello world" native Android app. I'll update this thread as I go, for anyone who's interested.
Nov 25 2013
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Monday, 25 November 2013 at 10:38:24 UTC, Joakim wrote:
 On Friday, 22 November 2013 at 18:01:44 UTC, Joakim wrote:
 I spent some time setting up the appropriate VMs and looking 
 at the relevant Android dev tools myself.  It appears that the 
 Android NDK uses a lightly patched version of stock llvm/clang 
 3.3, along with the gold linker.  Their patches are available 
 online:

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

 Their llvm is the same as llvm 3.3 until commit ce33750 and 
 clang is the same until commit 20c7d45.  The stock llvm/clang 
 3.3 have some limited support for Android, not much.  I'm 
 going to start going through those patches next.

 Since there are only about 50-100 llvm/clang patches, many of 
 them architecture-specific and so not necessary, this suggests 
 that the Android ABI is not that different from linux.

there's little of significance. They hardcode two clang options for android/x86, -mstackrealign and -msse3, add a few tweaks for ARM, and that's about it. Most of the patches are for some other NDK work by MediaTek, which don't appear to be used by the official Android NDK. I was able to compile an identical stripped shared library from the samples just by using the stock clang 3.3 that's installed in Arch linux, once I added the two hardcoded flags in with the rest of the flags their makefiles generate, so you really don't even need to use their compiler, at least for Android/x86. Next step, get dmd to do the same with a "hello world" native Android app. I'll update this thread as I go, for anyone who's interested.

Thanks, I'm interested.
Nov 25 2013
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
On Monday, 25 November 2013 at 11:32:56 UTC, Chris wrote:
 On Monday, 25 November 2013 at 10:38:24 UTC, Joakim wrote:
 Next step, get dmd to do the same with a "hello world" native 
 Android app.  I'll update this thread as I go, for anyone 
 who's interested.

Thanks, I'm interested.

world" app on linux/x86 without druntime and phobos, so I might as well document it here. After looking at a bunch of old newsgroup posts and some druntime source, I came up with the following foo.d: extern (C) void puts(const char*); extern (C) int main() {puts("Booya cuddie!\n");return 0;} I compiled foo.d with a local, unpatched build of dmd from git as of 10 days ago, dmd compiled by clang++: ./src/dmd -v foo.d -betterC -defaultlib= No good, it wants an object.d, despite being a better C: Error: cannot find source code for runtime library file 'object.d' dmd might not be correctly installed. Run 'dmd -man' for installation instructions. Specify path to file 'object.d' with -I switch So I copied object.di from druntime into the same directory, but it turns out that simply placing an empty file called object.di there also works. :) Next error, it doesn't link: foo.o:(.text.d_dso_init[.data.d_dso_rec]+0x33): undefined reference to `_d_dso_registry' collect2: error: ld returned 1 exit status --- errorlevel 1 So I checked the symbols from the object file it did build:
 nm foo.o

U _GLOBAL_OFFSET_TABLE_ U _d_dso_registry 00000000 T main It turns out that there's a weak reference to _d_dso_registry for ELF object files, but it was recently made a requirement on linux only. I got rid of that requirement by changing the REQUIRE_DSO_REGISTRY define to this line in ./src/backend/elfobj.c: #define REQUIRE_DSO_REGISTRY (DMDV2 && TARGET_RLINUX) Recompile dmd and foo.d now builds and runs. :) Obviously, this patch shouldn't be necessary if you're not on linux. Next, getting this minimal app running on Android/x86. It turns out there is some support for building executables directly in the Android NDK, just undocumented, though the docs are fairly bad generally.
Nov 25 2013
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Monday, 25 November 2013 at 22:32:26 UTC, Joakim wrote:
 On Monday, 25 November 2013 at 11:32:56 UTC, Chris wrote:
 On Monday, 25 November 2013 at 10:38:24 UTC, Joakim wrote:
 Next step, get dmd to do the same with a "hello world" native 
 Android app.  I'll update this thread as I go, for anyone 
 who's interested.

Thanks, I'm interested.

"hello world" app on linux/x86 without druntime and phobos, so I might as well document it here. After looking at a bunch of old newsgroup posts and some druntime source, I came up with the following foo.d: extern (C) void puts(const char*); extern (C) int main() {puts("Booya cuddie!\n");return 0;} I compiled foo.d with a local, unpatched build of dmd from git as of 10 days ago, dmd compiled by clang++: ./src/dmd -v foo.d -betterC -defaultlib= No good, it wants an object.d, despite being a better C: Error: cannot find source code for runtime library file 'object.d' dmd might not be correctly installed. Run 'dmd -man' for installation instructions. Specify path to file 'object.d' with -I switch So I copied object.di from druntime into the same directory, but it turns out that simply placing an empty file called object.di there also works. :) Next error, it doesn't link: foo.o:(.text.d_dso_init[.data.d_dso_rec]+0x33): undefined reference to `_d_dso_registry' collect2: error: ld returned 1 exit status --- errorlevel 1 So I checked the symbols from the object file it did build:
 nm foo.o

U _GLOBAL_OFFSET_TABLE_ U _d_dso_registry 00000000 T main It turns out that there's a weak reference to _d_dso_registry for ELF object files, but it was recently made a requirement on linux only. I got rid of that requirement by changing the REQUIRE_DSO_REGISTRY define to this line in ./src/backend/elfobj.c: #define REQUIRE_DSO_REGISTRY (DMDV2 && TARGET_RLINUX) Recompile dmd and foo.d now builds and runs. :) Obviously, this patch shouldn't be necessary if you're not on linux. Next, getting this minimal app running on Android/x86. It turns out there is some support for building executables directly in the Android NDK, just undocumented, though the docs are fairly bad generally.

Interesting. Johannes mentioned that the main app should always be in Java so it goes through Dalvik. I've done some JNI-D stuff already (only a proof-of-concept command line app though). I wonder what's the best way of porting D to mobile OS's (mainly Android and iOS).
Nov 26 2013
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
On Tuesday, 26 November 2013 at 09:53:07 UTC, Chris wrote:
 On Monday, 25 November 2013 at 22:32:26 UTC, Joakim wrote:
 Next, getting this minimal app running on Android/x86.  It 
 turns out there is some support for building executables 
 directly in the Android NDK, just undocumented, though the 
 docs are fairly bad generally.


Android/x86 4.3! :D I just compiled the object file with dmd patched to take out _d_dso_registry and using the invocation above, then linked it with the gold linker, Android libraries, and flags that the Android NDK uses, and ran it from a terminal in an Android/x86 VM. I was not looking forward to debugging arcane ABI issues and it looks like I may not have to. :) I think I'll just use this pure native route to port druntime for now.
 Interesting. Johannes mentioned that the main app should always 
 be in Java so it goes through Dalvik. I've done some JNI-D 
 stuff already (only a proof-of-concept command line app 
 though). I wonder what's the best way of porting D to mobile 
 OS's (mainly Android and iOS).

app, presumably that you distribute through the Play Store. But you can always build a native app for your own local dev build of Android, at least for porting purposes. But look at the test-libstdc++ sample app in the NDK: they actually build it as an executable, not a shared library. I haven't tested yet if that's a mistake or if it will actually work. In other words, I don't know if they enforce the shared library approach, whether technically or through some Play Store certification process, but it certainly is the officially blessed approach. What JNI-D stuff have you tried and on what platform, linux/x86? I'll try the shared library approach on Android at some point and report back.
Nov 26 2013
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
On Tuesday, 26 November 2013 at 11:22:59 UTC, Joakim wrote:
 That is what the docs say if you want to build a native Android 
 app, presumably that you distribute through the Play Store.  
 But you can always build a native app for your own local dev 
 build of Android, at least for porting purposes.

ie it doesn't have to be a shared library if you're just deploying it locally.
Nov 26 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Tue, 26 Nov 2013 12:36:19 +0100
schrieb "Joakim" <joakim airpost.net>:

 On Tuesday, 26 November 2013 at 11:22:59 UTC, Joakim wrote:
 That is what the docs say if you want to build a native Android 
 app, presumably that you distribute through the Play Store.  
 But you can always build a native app for your own local dev 
 build of Android, at least for porting purposes.

ie it doesn't have to be a shared library if you're just deploying it locally.

Native apps are working, just not officially supported. I actually had a native Hello World working on ARM/Android with GDC, however fixing bugs related to native apps usually isn't high priority on Android. This bug for example wasn't fixed back then and was a showstopper: http://code.google.com/p/android/issues/detail?id=28598 Last time I looked pure native apps couldn't use the GUI though, has that changed?
Nov 26 2013
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
On Tuesday, 26 November 2013 at 17:12:38 UTC, Johannes Pfau wrote:
 Native apps are working, just not officially supported. I 
 actually had
 a native Hello World working on ARM/Android with GDC, however 
 fixing
 bugs related to native apps usually isn't high priority on 
 Android.

 This bug for example wasn't fixed back then and was a 
 showstopper:
 http://code.google.com/p/android/issues/detail?id=28598

simply by using the right flags, as noted in the penultimate comment there. Also, I get the impression that the build system makefiles for Android itself are pretty much the same as the NDK, so Android would have some pretty serious problems if they didn't get their toolchain for building native system, ie non-java, processes working right. ;)
 Last time I looked pure native apps couldn't use the GUI 
 though, has
 that changed?

devs, so you can't call the Android UI components directly from native code AFAIK. But you could use OpenGL ES 2.0 from Android 2.0 and employ EGL with a pure native shared library app since Android 2.3 in 2010, so you could employ your own OpenGL-based GUI toolkit for a long time: http://mobilepearls.com/labs/native-android-api/ndk/docs/STABLE-APIS.html And you could always use JNI to do your GUI in java and number-crunching in C/C++, but yeah, that's not pure native.
Nov 26 2013
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Tuesday, 26 November 2013 at 11:22:59 UTC, Joakim wrote:
 What JNI-D stuff have you tried and on what platform, 
 linux/x86?  I'll try the shared library approach on Android at 
 some point and report back.

If I remember correctly, I did something like this (think it was on OS X): 1. Create D library (seems to be necessary?) dmd -lib hello.d -oflibhelloD 2. Compile (do not link) gcc -c hello.c -o helloC.o // Calls D code 3. JNI (compile) gcc -c -I/path/to/Java/Headers Test.c -o Test.o // JNI file (calls hello.c) 4. Create library. gcc -dynamiclib -o libTest.jnilib -lphobos2 -lhelloD Test.o helloC.o And it worked. I don't know, if step 2. is necessary at all. I've also been able to successfully combine Python and D, so that the D module could be loaded and used by Python like any other module. I could also link D and Objective-C. But that was all on Desktop (Mac OS X and Linux). I haven't tried it for Android or iOS yet.
Nov 27 2013
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
On Wednesday, 27 November 2013 at 13:52:17 UTC, Chris wrote:
 On Tuesday, 26 November 2013 at 11:22:59 UTC, Joakim wrote:
 What JNI-D stuff have you tried and on what platform, 
 linux/x86?  I'll try the shared library approach on Android at 
 some point and report back.

If I remember correctly, I did something like this (think it was on OS X): 1. Create D library (seems to be necessary?) dmd -lib hello.d -oflibhelloD 2. Compile (do not link) gcc -c hello.c -o helloC.o // Calls D code 3. JNI (compile) gcc -c -I/path/to/Java/Headers Test.c -o Test.o // JNI file (calls hello.c) 4. Create library. gcc -dynamiclib -o libTest.jnilib -lphobos2 -lhelloD Test.o helloC.o And it worked. I don't know, if step 2. is necessary at all. I've also been able to successfully combine Python and D, so that the D module could be loaded and used by Python like any other module. I could also link D and Objective-C. But that was all on Desktop (Mac OS X and Linux). I haven't tried it for Android or iOS yet.

Hmm, that seems pretty convoluted, hopefully it won't be as bad on Android. I've started porting core.stdc from druntime to Android, so far, so good. One oddity I've run into is that stderr doesn't work properly on half of the existing OS platforms. Take this test file: //test.d import core.stdc.stdio; extern (C) int main() { fputs("doing this for real?", stderr); return 0;} It doesn't link on Win32, Win64, or Android. It works on linux and FreeBSD. Here's the output on platforms where it doesn't work: Win 7 x64 with dmd 2.064.2: C:\dmd2>.\windows\bin\dmd.exe -m32 test.d OPTLINK (R) for Win32 Release 8.00.13 Copyright (C) Digital Mars 1989-2010 All rights reserved. http://www.digitalmars.com/ctg/optlink.html test.obj(test) Error 42: Symbol Undefined _stderr --- errorlevel 1 C:\dmd2>.\windows\bin\dmd.exe -m64 test.d test.obj : error LNK2019: unresolved external symbol stderr referenced in functi on main test.exe : fatal error LNK1120: 1 unresolved externals --- errorlevel 1120 Arch linux x86 compiling for Android x86: test.o:test.d:function main: error: undefined reference to 'stderr' The linker seems to find the symbol for stderr on platforms where it's defined extern in libc. On platforms like Android, with the following stdio.h and stdio.d, not so much. Android: stdio.h: __BEGIN_DECLS extern FILE __sF[]; __END_DECLS --snip-- #define stdin (&__sF[0]) #define stdout (&__sF[1]) #define stderr (&__sF[2]) https://android.googlesource.com/platform/bionic/+/master/libc/include/stdio.h My stdio.d: else version( Android ) { enum { _IOFBF = 0, _IOLBF = 1, _IONBF = 2, } private extern shared FILE[3] __sF; shared stdin = &__sF[0]; shared stdout = &__sF[1]; shared stderr = &__sF[2]; } I followed the example of Solaris and Win32, but it appears those don't work either. My guess is that OS X will work and Solaris won't, based on these similarities, but I don't have either accessible to test on. If I call &__sF[2] directly from test.d, that does work on Android. So the question is, when one has a #define macro like the above, how does one create the equivalent symbol in D? It appears that the authors of druntime are unsure of how to do this also.
Dec 01 2013
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
Alright, submitted my first pull request for Android support in 
druntime:

https://github.com/D-Programming-Language/druntime/pull/681

I'll push all further changes to druntime in my android branch:

https://github.com/joakim-noah/druntime/tree/android

Hopefully, I can get some subset of D working on Android/x86 over 
the next couple weeks. :)
Dec 01 2013
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
On Monday, 2 December 2013 at 08:25:39 UTC, Rainer Schuetze wrote:
 On 01.12.2013 14:30, Joakim wrote:
 //test.d
 import core.stdc.stdio;

 extern (C) int main() { fputs("doing this for real?", stderr); 
 return 0;}

 It doesn't link on Win32, Win64, or Android.  It works on 
 linux and
 FreeBSD.  Here's the output on platforms where it doesn't work:

The reason this does not work on Win32/Win64 comes from declaring main as "extern(C)", which declares "main" for the C runtime. This prevents adding an implicite include directive to add the phobos library to the link. This happens only for D's main.

linkage for main fixes the linking problem on Win32/Win64. That makes sense that druntime/phobos wasn't added to the link, as the symbols _were_ added by the above stdio.d for Android. Where is this "implicit include directive?" It's confusing because "dmd -v" shows the exact same linker command being run whether that "extern (C)" is there before main or not.
 So, you should either drop the "extern(C)" or add phobos.lib to 
 the command line.

 If including the library is not an option, you'll have to 
 repeat the respective declarations in your source. Just adding 
 core.stdc.stdio to the command line might also work.

archiving the ported core.stdc druntime object files for Android into a libphobos2.a, as that library name is hardcoded into dmd. Perhaps that was a mistake, I'll look further into why it doesn't link.
Dec 02 2013
prev sibling next sibling parent =?UTF-8?B?Ikx1w61z?= Marques" <luis luismarques.eu> writes:
Yes, ARM D support is really important.

https://josephscott.org/archives/2013/12/is-facebook-planning-a-move-to-arm-based-servers/

BTW, it might be a good idea to also target ARM64, while we're at 
it...
Dec 13 2013
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
On Friday, 13 December 2013 at 17:18:30 UTC, Luís Marques wrote:
 Yes, ARM D support is really important.

 https://josephscott.org/archives/2013/12/is-facebook-planning-a-move-to-arm-based-servers/

It also came out today that Google is thinking about designing custom ARM chips to put in their servers: http://www.theverge.com/2013/12/13/5206420/google-arm-chips-for-servers-rumor
 BTW, it might be a good idea to also target ARM64, while we're 
 at it...

Phobos seems to be largely arch-independent. Druntime has some limited ARM support and Martin committed the first druntime patch that references AARCH64 a couple months back: :) https://github.com/D-Programming-Language/druntime/commit/6803132b0d76ef895718fe8f0e835bf8dc3d0ecf#diff-4c8de49e7eb91f21fda73e8133fea05aR219 The missing piece is that dmd doesn't have an ARM backend. The other D compilers do however, and Apple plans to open-source their custom AARCH64 backend and merge it into the existing one in llvm soon: http://www.phoronix.com/scan.php?page=news_item&px=MTQ1ODM So I imagine D users will have ARM/AARCH64 support at some point next year, depending on how long it takes to put all the pieces together.
Dec 13 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
--001a11c1ca6019943904ed7d2bce
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Dec 13, 2013 8:40 PM, "Joakim" <joakim airpost.net> wrote:
 On Friday, 13 December 2013 at 17:18:30 UTC, Lu=EDs Marques wrote:
 Yes, ARM D support is really important.


-based-servers/
 It also came out today that Google is thinking about designing custom ARM


or
 BTW, it might be a good idea to also target ARM64, while we're at it...

Phobos seems to be largely arch-independent. Druntime has some limited

AARCH64 a couple months back: :)

718fe8f0e835bf8dc3d0ecf#diff-4c8de49e7eb91f21fda73e8133fea05aR219
 The missing piece is that dmd doesn't have an ARM backend.  The other D

backend and merge it into the existing one in llvm soon:
 http://www.phoronix.com/scan.php?page=3Dnews_item&px=3DMTQ1ODM

 So I imagine D users will have ARM/AARCH64 support at some point next

And assuming someone doesn't write some new x86 centric module to replace the well tested, architecture independent implementation just because you can't use it in ctfe. Regards --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0'; --001a11c1ca6019943904ed7d2bce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <p><br> On Dec 13, 2013 8:40 PM, &quot;Joakim&quot; &lt;<a href=3D"mailto:joakim ai= rpost.net">joakim airpost.net</a>&gt; wrote:<br> &gt;<br> &gt; On Friday, 13 December 2013 at 17:18:30 UTC, Lu=EDs Marques wrote:<br> &gt;&gt;<br> &gt;&gt; Yes, ARM D support is really important.<br> &gt;&gt;<br> &gt;&gt; <a href=3D"https://josephscott.org/archives/2013/12/is-facebook-pl= anning-a-move-to-arm-based-servers/">https://josephscott.org/archives/2013/= 12/is-facebook-planning-a-move-to-arm-based-servers/</a><br> &gt;<br> &gt;<br> &gt; It also came out today that Google is thinking about designing custom = ARM chips to put in their servers:<br> &gt;<br> &gt; <a href=3D"http://www.theverge.com/2013/12/13/5206420/google-arm-chips= -for-servers-rumor">http://www.theverge.com/2013/12/13/5206420/google-arm-c= hips-for-servers-rumor</a><br> &gt;<br> &gt;<br> &gt;&gt; BTW, it might be a good idea to also target ARM64, while we&#39;re= at it...<br> &gt;<br> &gt;<br> &gt; Phobos seems to be largely arch-independent. =A0Druntime has some limi= ted ARM support and Martin committed the first druntime patch that referenc= es AARCH64 a couple months back: :)<br> &gt;<br> &gt; <a href=3D"https://github.com/D-Programming-Language/druntime/commit/6= 803132b0d76ef895718fe8f0e835bf8dc3d0ecf#diff-4c8de49e7eb91f21fda73e8133fea0= 5aR219">https://github.com/D-Programming-Language/druntime/commit/6803132b0= d76ef895718fe8f0e835bf8dc3d0ecf#diff-4c8de49e7eb91f21fda73e8133fea05aR219</= a><br> &gt;<br> &gt; The missing piece is that dmd doesn&#39;t have an ARM backend. =A0The = other D compilers do however, and Apple plans to open-source their custom A= ARCH64 backend and merge it into the existing one in llvm soon:<br> &gt;<br> &gt; <a href=3D"http://www.phoronix.com/scan.php?page=3Dnews_item&;px=3D= MTQ1ODM">http://www.phoronix.com/scan.php?page=3Dnews_item&;px=3DMTQ1ODM= </a><br> &gt;<br> &gt; So I imagine D users will have ARM/AARCH64 support at some point next = year, depending on how long it takes to put all the pieces together.</p> <p>And assuming someone doesn&#39;t write some new x86 centric module to re= place the well tested, architecture independent implementation just because= you can&#39;t use it in ctfe.</p> <p>Regards<br> -- <br> Iain Buclaw</p> <p>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;;</p> --001a11c1ca6019943904ed7d2bce--
Dec 14 2013
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
On Monday, 2 December 2013 at 18:35:36 UTC, Rainer Schuetze wrote:
 On 02.12.2013 10:36, Joakim wrote:
 Where is this "implicit include directive?"  It's confusing 
 because "dmd
 -v" shows the exact same linker command being run whether that 
 "extern
 (C)" is there before main or not.

The compiler embeds it into the object file if code for "D main" is generated. The respective code is around line 742, glue.c.

 IIRC it is not possible to embed a linker directive into an ELF 
 object file, so it must always be specified on the command 
 line. Maybe the linker is looking for libphobos2.a in the wrong 
 directories?

object file that dmd compiled when linking and the linker order was biting me. It worked fine with the wrong linker order as long as I didn't reference symbols like stderr from druntime, because it was getting stdc function symbols from libc anyway, but would crap out when the stderr symbol was needed from druntime. As usual, the problem was user error. :) I just got a basic D program running with a patched druntime on Android/x86. :) I was also able to compile and run sieve.d from the D samples, after replacing std.stdio.writefln with core.stdc.stdio.printf and moving the flags declaration inside main. It would segfault at "flags[]=true" if I didn't move that declaration inside, so there are obviously still some scoping issues, perhaps because I haven't ported all of druntime to Android yet, only about halfway done.
Dec 15 2013
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
 I just got a basic D program running with a patched druntime on 
 Android/x86. :) I was also able to compile and run sieve.d from 
 the D samples, after replacing std.stdio.writefln with 
 core.stdc.stdio.printf and moving the flags declaration inside 
 main.  It would segfault at "flags[]=true" if I didn't move 
 that declaration inside, so there are obviously still some 
 scoping issues, perhaps because I haven't ported all of 
 druntime to Android yet, only about halfway done.

I finished porting most of druntime to Android/x86 and have started trying to run the tests: I just got 31 out of 38 druntime modules' unit tests to pass. :) I figured out the segfault mentioned above was because TLS is done differently on Android- flags[] is a global when outside main and thread-local by default as a result, adding a shared attribute makes it work again- and I was getting a lot of segfaults on the unit tests for the same reason. After making all the simple globals in the unit tests, like cpuid in rt.arrayfloat/int/etc., into shared variables, only 8 modules' unittests segfault, one after passing. Bionic doesn't support __thread for TLS, but it does let you use the pthread_key_(create|delete)/pthread_(set|get)specific APIs, just as druntime does on OS X. Here's the bionic implementation: https://github.com/android/platform_bionic/blob/master/libc/bionic/pthread_key.cpp I haven't completely grasped TLS and how it's done on OS X yet, but I get the sense I'll have to modify dmd a little to get TLS working with bionic. It appears that Martin and Johannes have looked into this before, so if you two have any feedback, let me know. I'm hoping TLS is the last remaining piece for druntime to be finished porting to Android/x86, then I want to try Phobos, which I'm guessing shouldn't be as bad.
Dec 28 2013
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
On Saturday, 28 December 2013 at 22:21:46 UTC, Joakim wrote:
 I finished porting most of druntime to Android/x86 and have 
 started trying to run the tests: I just got 31 out of 38 
 druntime modules' unit tests to pass. :)

 I figured out the segfault mentioned above was because TLS is 
 done differently on Android- flags[] is a global when outside 
 main and thread-local by default as a result, adding a shared 
 attribute makes it work again- and I was getting a lot of 
 segfaults on the unit tests for the same reason.  After making 
 all the simple globals in the unit tests, like cpuid in 
 rt.arrayfloat/int/etc., into shared variables, only 8 modules' 
 unittests segfault, one after passing.

 Bionic doesn't support __thread for TLS, but it does let you 
 use the pthread_key_(create|delete)/pthread_(set|get)specific 
 APIs, just as druntime does on OS X.  Here's the bionic 
 implementation:

 https://github.com/android/platform_bionic/blob/master/libc/bionic/pthread_key.cpp

 I haven't completely grasped TLS and how it's done on OS X yet, 
 but I get the sense I'll have to modify dmd a little to get TLS 
 working with bionic.  It appears that Martin and Johannes have 
 looked into this before, so if you two have any feedback, let 
 me know.

 I'm hoping TLS is the last remaining piece for druntime to be 
 finished porting to Android/x86, then I want to try Phobos, 
 which I'm guessing shouldn't be as bad.

to get all 38 druntime modules' unit tests to pass on Android/x86... under somewhat random conditions. It's finicky and some of the tests start failing and many segfaulting on exit, as mentioned before, if I make minor changes to the unit tests, like changing some TLS globals to shared. I'm guessing this is because I don't really have TLS working yet, I'm just taking advantage of the fact that the baked-in TLS in linux kinda sorta still works on Android. As long as it's local-exec, uninitialized TLS mostly works if it's less than 4-5 KB, while initialized TLS doesn't get initialized correctly. Of course, it's possible that I'm hitting some other codegen incompatibility altogether, unrelated to TLS, but the fact that it sometimes works depending on the number of TLS variables makes me think it's a TLS issue. I also got a bit more than half of the Phobos unit tests to pass, with a lot of seg faults there too. Android is going to need a packed TLS approach, similar to what Walter implemented for OS X with dmd: http://www.drdobbs.com/architecture-and-design/implementing-thread-local-storage-on-os/228701185 I've been looking into doing something similar for ELF, but this is the first time hacking on a compiler for me. If someone else more familiar with dmd or ldc could put packed TLS for ELF together more quickly, that would certainly speed things up. If not, I'll have something together eventually. ;)
Mar 21 2014
prev sibling next sibling parent "Joakim" <dlang joakim.airpost.net> writes:
On Friday, 21 March 2014 at 19:59:41 UTC, Joakim wrote:
 Been awhile since I updated on the Android effort: I'm now able 
 to get all 38 druntime modules' unit tests to pass on 
 Android/x86... under somewhat random conditions.  It's finicky 
 and some of the tests start failing and many segfaulting on 
 exit, as mentioned before, if I make minor changes to the unit 
 tests, like changing some TLS globals to shared.  I'm guessing 
 this is because I don't really have TLS working yet, I'm just 
 taking advantage of the fact that the baked-in TLS in linux 
 kinda sorta still works on Android.

 As long as it's local-exec, uninitialized TLS mostly works if 
 it's less than 4-5 KB, while initialized TLS doesn't get 
 initialized correctly.  Of course, it's possible that I'm 
 hitting some other codegen incompatibility altogether, 
 unrelated to TLS, but the fact that it sometimes works 
 depending on the number of TLS variables makes me think it's a 
 TLS issue.  I also got a bit more than half of the Phobos unit 
 tests to pass, with a lot of seg faults there too.

 Android is going to need a packed TLS approach, similar to what 
 Walter implemented for OS X with dmd:

 http://www.drdobbs.com/architecture-and-design/implementing-thread-local-storage-on-os/228701185

 I've been looking into doing something similar for ELF, but 
 this is the first time hacking on a compiler for me.  If 
 someone else more familiar with dmd or ldc could put packed TLS 
 for ELF together more quickly, that would certainly speed 
 things up.  If not, I'll have something together eventually. ;)

Alright, finally hacked dmd to produce something like packed TLS for ELF. I just ran the druntime unit tests on Android/x86 and all 38 modules passed, :) even after changing the number of TLS variables a couple times, which was causing segfaults with the native TLS before. I'll try running the phobos unit tests next, then building a sample Android/x86 D app/apk, ie the kind you can actually install on Android.
Apr 23 2014
prev sibling parent "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Thursday, 14 November 2013 at 14:47:47 UTC, Chris wrote:
 I know, I know, this question has been asked many times before. 
 But it came up in a meeting the other day: is there any work 
 being done on making D an ARM citizen so that _non-trivial_ D 
 code can be ported to smartphones and the like? If so, what it 
 the rough time frame?

I have few small/toy D apps running on my ODROID-U2 . They are compiled using latest GDC (4.8 branch). It all works fine. Yeah, phobos is 40+MiB big, but I have gibibytes free on emmc card! ;)
Apr 23 2014