[droid] - allow to build android for x86 platforms

[Memphiz]

As the title says. This is more of a RFC. As you can see there are some strange mixups here where we checked for toolchains like android-linux-gnu. I have adapted it so it compiles with my osx toolchain which is called i686-linux-android (which is inline with the arm*-linux-android naming sheme).

Maybe someone ( @tnelson volunteered? :D) could check the x86 toolchain name on linux.

I have test compiled this with vanilla android ndk r9 (gcc 4.7 toolchain).

pythonmodule-pil is still unsolved when compiled from osx host (not sure if this is an issue on linux aswell). @theuni was informed and pinged for that already ;) (for my testbuilds i just skipped building it...)

[t-nelson]

So then...

trent@farnsworth:/opt/toolchain/android-ndk-r7-crystax-5.beta3/toolchains/x86-4.4.3/prebuilt/linux-x86/bin$ ls -1 *gcc
i686-android-linux-gcc
i686-linux-android-gcc

And it gets worse

trent@farnsworth:/opt/toolchain/android-ndk-r7-crystax-5.beta3/toolchains/x86-4.4.3/prebuilt/linux-x86/bin$ diff *gcc
Binary files i686-android-linux-gcc and i686-linux-android-gcc differ

You're welcome?

[theuni]

Ignore crystax and anything before r8b. The x86 toolchain was renamed correctly there. i686-linux-android-* is the correct schema.

[theuni]

Fyi, this build did actually work at the time Android was merged. I believe it was building correctly with crystax7b3. The changes in this PR will break x86 builds on older NDKs, but since we have never built/shipped binaries for x86, or made any attempt to support it, I see no problem with that.

My suggestion is to test out r9 + gcc4.7 on arm and x86, and if all seems good, bump the docs to reflect that for all arches. This is nice actually, since both toolchains should be working well enough now, so no special hacks are needed (for ex, the sigsetjmp note can be removed from docs).

[Memphiz]

yep - i built arm too and it worked (tested on odroid-x) - beside the pythonmodule-pil thingy.

Only thing is that the gcc-4.7 toolchain was an extra download called "legacy toolchains" - in the r9ndk was only gcc 4.6 and gcc 4.8 and clang 3.2 and clang3.3.

I also noticed the libc hack isn't needed anymore. I will add a commit with adaption of the readme.

@theuni is it worth to try anything else then gcc 4.7? (as it somehow doesn't ship with r9 directly)

[theuni]

Hmm, odd choice for them to deprecate 4.7 now that it's nice and stable...

So yes, if we're going to be using r9, we should be keeping up with the suggested toolchains. And more importantly, we should be as toolchain-independent as possible, so any fixes needed to build with other compilers are valid fixes regardless of ndk decisions.

4.7 was the first version that brought in all we needed, so the logical move is to 4.8. I saw a report from a forum user failing to build with 4.8 which died at ffmpeg, which is a good sign because that's very late in the overall build. I don't recall the error exactly (impossible constraint iirc), but it could be what was fixed by e493c5c, which has been effectively reverted in our newer ffmpeg.

[Memphiz]

Updated:

1. checking for --linux-android now for getting the TARGET_* defines equal for arm and x86 builds
2. Updated README.android as mentioned in the commit msg...

[theuni]

Hmm, arm builds with 4.8 as-is?

[Memphiz]

after 1c7def4 - yes :)

[Memphiz]

@theuni - should we merge it?

[Memphiz]

superseeded by #3256