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" <[email protected]>:
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).
