I expermented with building D for Android within a Debian chroot. I was able to get D to build with GCC 4.7.1 under ARM. I went to compile a test program with D   using the _Dmodule_ref shim and nophoboslib flag, however in testing argv[0] to printf output, the linker said it couldn't reference the _d_array_1 function or something similar. I deleted the compiler out of frustation (I spent a week getting it to build on arm). Did I have to manually link gdruntime.a in afterthought?

On 19 September 2012 17:12, Kris Dawson <gnerdthe1@gmail.com> wrote:
> I expermented with building D for Android within a Debian chroot. I was able to get D to build with GCC 4.7.1 under ARM. I went to compile a test program with D   using the _Dmodule_ref shim and nophoboslib flag, however in testing argv[0] to printf output, the linker said it couldn't reference the _d_array_1 function or something similar. I deleted the compiler out of frustation (I spent a week getting it to build on arm). Did I have to manually link gdruntime.a in afterthought?


I would say no.  But without a copy of the build, is not easy to tell.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Am Wed, 19 Sep 2012 18:12:51 +0200
schrieb "Kris Dawson" <gnerdthe1@gmail.com>:

> I expermented with building D for Android within a Debian chroot. I was able to get D to build with GCC 4.7.1 under ARM. I went to compile a test program with D   using the _Dmodule_ref shim and nophoboslib flag, however in testing argv[0] to printf output, the linker said it couldn't reference the _d_array_1 function or something similar. I deleted the compiler out of frustation (I spent a week getting it to build on arm). Did I have to manually link gdruntime.a in afterthought?

IIRC the installation instructions and public repositories do not have a working libdruntime yet. So you probably only have the compiler, but not the runtime (that's also why the _Dmodule_ref hack is necessary).

Seems like accessing an array needs the _d_array_1 function, so that doesn't work. You currently can do almost nothing without a runtime. I hope that might change in the future or we would see tiny replacement runtimes, but for now you need druntime for almost everything.

I gave up on Android for now (without TLS in Android and proper .so support in D there's not much we can do), but I had druntime working.

I need to get all that old stuff cleaned up and post it somewhere so it doesn't get lost,  but don't hold your breath as I don't have much time for that right now.

BTW: If you only want to use D on ARM, try the Raspberry PI or the PandaBoard, BeagleBoard, TrimSlice, etc. The problems described above are Android problems, not ARM problems. There's one big problem with all ARM devices (issue #120), but I have a fix which should be almost ready. I just have to run the testsuite on a few architectures to make sure there are no regressions.

On 19 September 2012 18:57, Johannes Pfau <nospam@example.com> wrote:
> Am Wed, 19 Sep 2012 18:12:51 +0200
> schrieb "Kris Dawson" <gnerdthe1@gmail.com>:
>
>> I expermented with building D for Android within a Debian chroot. I was able to get D to build with GCC 4.7.1 under ARM. I went to compile a test program with D   using the _Dmodule_ref shim and nophoboslib flag, however in testing argv[0] to printf output, the linker said it couldn't reference the _d_array_1 function or something similar. I deleted the compiler out of frustation (I spent a week getting it to build on arm). Did I have to manually link gdruntime.a in afterthought?
>
> IIRC the installation instructions and public repositories do not have a working libdruntime yet. So you probably only have the compiler, but not the runtime (that's also why the _Dmodule_ref hack is necessary).
>
> Seems like accessing an array needs the _d_array_1 function, so that doesn't work. You currently can do almost nothing without a runtime. I hope that might change in the future or we would see tiny replacement runtimes, but for now you need druntime for almost everything.
>
> I gave up on Android for now (without TLS in Android and proper .so support in D there's not much we can do), but I had druntime working.
>
> I need to get all that old stuff cleaned up and post it somewhere so it doesn't get lost,  but don't hold your breath as I don't have much time for that right now.
>
> BTW: If you only want to use D on ARM, try the Raspberry PI or the PandaBoard, BeagleBoard, TrimSlice, etc. The problems described above are Android problems, not ARM problems. There's one big problem with all ARM devices (issue #120), but I have a fix which should be almost ready. I just have to run the testsuite on a few architectures to make sure there are no regressions.

On top of that, I've finally got my Sheevaplug back - will build a Linux x86 -> Linux ARM compiler for Ubuntu 12.10 - can stick the files up on my server (infact, if anyone has any binaries / source build folders that may be of use, send them my way).


Regards

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Wednesday, 19 September 2012 at 17:56:55 UTC, Johannes Pfau wrote:
> Am Wed, 19 Sep 2012 18:12:51 +0200
> schrieb "Kris Dawson" <gnerdthe1@gmail.com>:
>
>> I expermented with building D for Android within a Debian chroot. I was able to get D to build with GCC 4.7.1 under ARM. I went to compile a test program with D   using the _Dmodule_ref shim and nophoboslib flag, however in testing argv[0] to printf output, the linker said it couldn't reference the _d_array_1 function or something similar. I deleted the compiler out of frustation (I spent a week getting it to build on arm). Did I have to manually link gdruntime.a in afterthought?
>
> IIRC the installation instructions and public repositories do not have a
> working libdruntime yet. So you probably only have the compiler, but
> not the runtime (that's also why the _Dmodule_ref hack is necessary).
>
> Seems like accessing an array needs the _d_array_1 function, so that
> doesn't work. You currently can do almost nothing without a runtime. I
> hope that might change in the future or we would see tiny replacement
> runtimes, but for now you need druntime for almost everything.
>
> I gave up on Android for now (without TLS in Android and proper .so
> support in D there's not much we can do), but I had druntime working.
>
> I need to get all that old stuff cleaned up and post it somewhere so
> it doesn't get lost,  but don't hold your breath as I don't have much
> time for that right now.
>
> BTW: If you only want to use D on ARM, try the Raspberry PI or the
> PandaBoard, BeagleBoard, TrimSlice, etc. The problems described above
> are Android problems, not ARM problems. There's one big problem with
> all ARM devices (issue #120), but I have a fix which should be almost
> ready. I just have to run the testsuite on a few architectures to make
> sure there are no regressions.

Ok, was just making sure. I wanted to focus on Android because of the range of devices (specifically tablets are my interest).
I believe full Linux for tablets and phones is the next step in those devices being adopted as full computing environments. The iOS and Win 8 proprietary options are purposely still too limited (especially the first).

Ok, I checked out a wiki on Raspberry PI in which they got D to compile with GCC 4.8.
Would compiling D for the armhf Debian image I'm already running on my Android device be able to produce binaries for Android by either statically linking my code (it works for gcc) or by setting the -dynamic-linker flag to Android's linker
binary and compiling with the appropiate ARM CPU crt object file?

Am Sun, 23 Sep 2012 00:15:36 +0200
schrieb "Kris Dawson" <gnerdthe1@gmail.com>:

> Ok, I checked out a wiki on Raspberry PI in which they got D to
> compile with GCC 4.8.
> Would compiling D for the armhf Debian image I'm already running
> on my Android device be able to produce binaries for Android by
> either statically linking my code (it works for gcc) or by
> setting the -dynamic-linker flag to Android's linker
> binary and compiling with the appropiate ARM CPU crt object file?

It's probably possible if you link libc statically. But it's usually not advised to do this, as it has other issues.