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.

On Friday, 15 November 2013 at 09:45:42 UTC, Paulo Pinto wrote:
> As far as I know dmd does not support cross compiling.
I started skimming the dmd source to see how it handled porting 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.

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 ...

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.

On Friday, 15 November 2013 at 11:46:29 UTC, Chris wrote:
> I see that it's still a big big issue.
It's not that much effort. Build gdc for ARM and fix druntime.

> I believe we really have to push this, because ARM support is vital.
Well somebody has to do it, so if you have so much interest in this...

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.
> I started skimming the dmd source to see how it handled porting 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

Bionic even got [dl_iterate_phdr](https://github.com/android/platform_bionic/commit/24053a461e7a20f34002262c1bb122023134989) which we need for shared library support.
Write me a mail if you hit any druntime issues during the port.

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

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

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