Hello Jim,
On Mon, 9 May 2011 19:01:43 +0800 Jim Huang jim.huang@linaro.org wrote:
On 9 May 2011 00:40, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
(sorry, first time sent from wrong email, don't know if that'll get thru)
Hello Android team,
hi Paul,
It is my pleasure to discuss with you.
I was working on making Android toolchain buildable using Android build service, and finally I was able to do successful and reproducible builds - of AOSP pristine bare-matal toolchain so far (https://android-build.linaro.org/builds/~pfalcon/aosp-toolchain/). There were few issues which needed to be investigated and resolved, and which I would like to discuss here:
In my humble opinion, AOSP toolchain ought to keep the same from Google binary delivery since we have no official documentation about Google's build environment and detailed instructions.
I agree. But the talk is more about performing reliable builds of an Android toolchain - taken from any source, of which AOSP is one (known good apparently). It just happen to be that pristine AOSP toolchain build is already here (Linaro-optimized to follow of course).
Linaro wiki contains one comprehensive page: https://wiki.linaro.org/Platform/Android/UpstreamToolchain
Well, doing continuous build in the cloud uncovered bunch of issues not discussed there ;-).
Although we can build on our own, it is unofficial and not fully the same as Google's.
- make -jN breakage
Android build service builds on EC2 XLARGE instances with 16 concurrent make jobs (-j16). This invariably leads to build failure sooner or later (exact location depends on other options and maybe non-deterministic at all). The failure is "error: Link tests are not allowed after GCC_NO_EXECUTABLES." which somehow sends issue-hunting the wrong trail (like sysroot issues, etc.) but after some experiments I reduced this to exactly -j >1 being used, with -j1 it went past usual failure points reliably.
Agree. Using -j1 is safe.
Ok, is it well-known fact that using N>1 is unsafe? If no, should we do something about it?
- Lack of DESTDIR support
There's standard GNU autotools variable "DESTDIR" to install package into other directory besides $prefix. It is supported for gcc, binutils, etc., but not for Android's own toolchain/build project. The usual local-use trick is just to pass another prefix just for make install target, and that's what toolchain/build's README suggests. My only concern is "cleanroomness" of the results - suppose make install suddenly wants to rebuild something (libtool used to have such habit), then new prefix may be embedded into some executable, and then hit beyond the usual usage pattern (like, with non-English locale). Still, this is more a theoretical risk, which I as a build engineer should note, but not something to much worry about.
If you were looking into recent change in AOSP, more target are going to be installed for unknown reasons.
I don't think it is a problem though once we have specific manners.
- libstdc++v3 build
toolchain/build's README says that the default is not to build libstdc++v3 and it must be enabled explicitly. But in the current master I found that not to be the case - it gets enabled by default. And its build requires sysroot, so I had to disable it explicitly for bare-metal build.
- sysroot source
Yes, you need to give sysroot while building toolchain.
You can get it from either NDK or built root file system.
Are there any differences using one vs another? Are there any risks using NDK's?
There're following sessions dedicated to Android continuous builds and/or toolchains, let's discuss these questions within their scope:
https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-o-conti... https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-o-toolc...
So, to build full-fledged toolchain, we need to supply sysroot. What should be source of it?
Thanks, -jserv