[Tutorial][Binaries] gdc for android

[Manu]

On 6 February 2012 09:40, Johannes Pfau <nospam at example.com> wrote:

> Am Mon, 6 Feb 2012 03:07:31 +0200
> schrieb Manu <turkeyman at gmail.com>:
>
> > On 6 February 2012 02:25, Manu <turkeyman at gmail.com> wrote:
> >
> > > On 6 February 2012 00:04, Johannes Pfau <nospam at example.com> wrote:
> > >
> > >> Am Sun, 5 Feb 2012 18:04:12 +0100
> > >> schrieb Johannes Pfau <nospam at example.com>:
> > >>
> > >> > I will probably need some more time to get this working...
> > >> >
> > >>
> > >> I have some good news:
> > >> http://www.mediafire.com/?107we120sh3xx
> > >>
> > >> I fixed that problem and then the whole build worked fine. I'll
> > >> post build instructions soon, but the binaries are ready. I only
> > >> did a simple gdc -c test.d to check the compiler, but it seems to
> > >> work.
> > >>
> > >> Linking against druntime fails, as it uses functions which are not
> > >> available on Android (backtrace, signal stuff).
> > >>
> > >> I also built a simple hello world on linux (printf, no runtime)
> > >> and ran it on my android phone, and it worked!
> > >>
> > >> In case you haven't used GDC without runtime before, a short
> > >> introduction:
> > >>
> > >> * use gdc -nophoboslib to make gdc not link against phobos (and
> > >> afaik, druntime)
> > >> * theres also -nostdlib in case you need it
> > >> * complex code may require -fno-section-anchors because of bug #120
> > >> * You'll get an error about a missing _Dmodule_ref symbol. That
> > >> symbol is used by module constructors and not generated by gdc if
> > >>  -nophoboslib was passed. As long as you don't run the module
> > >>  constructors, you can add a fake _Dmodule_ref in a .c file:
> > >>
> > >> ------------
> > >> void* _Dmodule_ref;
> > >> ------------
> > >>
> > >> * The compiler defines version(Android)
> > >>
> > >> Here's my hello world:
> > >> ------------
> > >> version(Android)
> > >> {
> > >>    pragma(msg, "Hello Android!");
> > >> }
> > >>
> > >> extern(C)
> > >> {
> > >>    int printf(in char* format, ...);
> > >> }
> > >>
> > >> extern(C) void main()
> > >> {
> > >>    printf("Hello, %s!\n".ptr, "Android".ptr);
> > >> }
> > >> ------------
> > >>
> > >> compile the _Dmodule_ref into hack.o, then use
> > >> gdc -nophoboslib hello.d hack.o
> > >>
> > >
> > > Amazing! You sir, are a genius!
> > > I'm gonna have to have some fun with that after work tomorrow :)
> > >
> > > I reckon this binary distro should be put on d-p-l somewhere
> > > obvious.
> > >
> >
> > I just tried with -mfpu=neon, which should allow GCC to generate neon
> > opcodes for the simd stuff, but it didn't seem to want to do that. In
> > fact it generates really horrible code where it CALLS an intrinsic
> > for each float in the vector...
> > Any idea why this wouldn't work out of the box?
>
> The android toolchain configures gcc with: += --with-float=soft
> --with-fpu=vfp --with-arch=armv5te
>
> I could try to build an optimized build, but then you'll have to tell
> me what processor you're using. Cortex A8?
>
> I'm not sure if you can override that at runtime. You could probably
> try:
> -mfloat-abi=hard -mcpu=cortex-a8 -march=armv7-a -mfpu=neon
>

That's interesting. I seem to recall in a recent NDK noticing that they had
changed to armv7 by default... but looking at the R6 NDK, it looks like
it's configured basically identical to your toolchain.
I must just be missing a whole function of compile options, but I can't see
any option in the standard build scripts to enable hardware fpu :/
The options I see that are supplied are: -ffast-math -mfloat-abi=softfp
-march=armv7-a

I imagine all android 2+ devices have at least armv7's with a hardware
fpu...

Interesting that NEON is not supported on all hardware. Annoying to do
runtime detection to take advantage of stuff like that >_<


> > I wanted to add ARM support to my std.simd work here as a better
> > proof of concept.
> >
> > Iain: was there anything particularly special you needed to do to
> > hook the x86 SSE stuff to GDC which would need to be duplicated for
> > ARM? gcc.builtins doesn't seen to have any ARM intrinsics in there
> > either...
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d.gnu/attachments/20120206/6cfe9887/attachment.html>