On 9 May 2011 00:40, Paul Sokolovsky <paul.sokolov...@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. Linaro wiki contains one comprehensive page: https://wiki.linaro.org/Platform/Android/UpstreamToolchain Although we can build on our own, it is unofficial and not fully the same as Google's. > 1. 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. > 2. 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. > 3. 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. > > 4. sysroot source > Yes, you need to give sysroot while building toolchain. You can get it from either NDK or built root file system. > So, to build full-fledged toolchain, we need to supply sysroot. > What should be source of it? Thanks, -jserv _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
