Hi, while working on some improvements, I noticed that our Android toolchain binaries are built as 32-bit x86. Is there any reason for this (other than "we inherited it from AOSP")?
While it doesn't matter much, it doesn't make much sense to me - Android can't currently be built on 32-bit machines (so it's not about having one binary that will work for mostly everyone - but I suspect that's exactly where it started back in the times of Android 1.0), so why introduce dependencies on a 32-bit libc and slow things down slightly?
If nobody complains, I'll remove the "-m32" flag from the Android toolchain builds - let's see how much we can speed up the build process itself without putting any real work into it...
ttyl bero
On Wed, Aug 10, 2011 at 4:29 PM, Bernhard Rosenkranzer bernhard.rosenkranzer@linaro.org wrote:
Hi, while working on some improvements, I noticed that our Android toolchain binaries are built as 32-bit x86. Is there any reason for this (other than "we inherited it from AOSP")?
While it doesn't matter much, it doesn't make much sense to me - Android can't currently be built on 32-bit machines (so it's not about having one binary that will work for mostly everyone - but I suspect that's exactly where it started back in the times of Android 1.0), so why introduce dependencies on a 32-bit libc and slow things down slightly?
If nobody complains, I'll remove the "-m32" flag from the Android toolchain builds - let's see how much we can speed up the build process itself without putting any real work into it...
That's a good question. It was an explicit decision from the past as we said we don't want to deviate from AOSP best practices unless we have very good arguments.
Also our binary toolchain will probably become more useful for 32-bit once we start talking about shipping NDK/SDK. Then, having just one binary to verify could turn out to be a smart thing.
If you feel strongly this should be changed in future, let's discuss during this month so we can work eventual changes into our 11.09 plan preparations.
Hello Alexander,
On Wed, 10 Aug 2011 16:48:23 +0200 Alexander Sack asac@linaro.org wrote:
[]
Also our binary toolchain will probably become more useful for 32-bit once we start talking about shipping NDK/SDK. Then, having just one binary to verify could turn out to be a smart thing.
Btw, NDK toolchain is build differently from "platform toolchain", and by separate set of scripts.
Bernhard Rosenkranzer wrote:
Hi, while working on some improvements, I noticed that our Android toolchain binaries are built as 32-bit x86. Is there any reason for this (other than "we inherited it from AOSP")?
While it doesn't matter much, it doesn't make much sense to me - Android can't currently be built on 32-bit machines (so it's not about
fwiw, android GB and HC both build fine on 32 bit here...
On 10 August 2011 09:20, Vladimir Pantelic vladoman@gmail.com wrote:
fwiw, android GB and HC both build fine on 32 bit here...
How so? Did you simply patch out the
ifeq ($(BUILD_OS),linux) build_arch := $(shell uname -m) ifneq (64,$(findstring 64,$(build_arch))) $(warning ************************************************************) $(warning You are attempting to build on a 32-bit system.) $(warning Only 64-bit build environments are supported beyond froyo/2.2.) $(warning ************************************************************) $(error stop) endif endif
part of build/core/main.mk? (I never understood why they put it there, but never bothered to question it and patch it out).
ttyl bero
On Wed, 10 Aug 2011 10:48:26 -0700 Bernhard Rosenkranzer bernhard.rosenkranzer@linaro.org wrote:
On 10 August 2011 09:20, Vladimir Pantelic vladoman@gmail.com wrote:
fwiw, android GB and HC both build fine on 32 bit here...
How so? Did you simply patch out the
ifeq ($(BUILD_OS),linux) build_arch := $(shell uname -m) ifneq (64,$(findstring 64,$(build_arch))) $(warning ************************************************************) $(warning You are attempting to build on a 32-bit system.) $(warning Only 64-bit build environments are supported beyond froyo/2.2.) $(warning ************************************************************) $(error stop) endif endif
part of build/core/main.mk? (I never understood why they put it there, but never bothered to question it and patch it out).
I personally did. I understand that what comes out is nothing official, but it helps to at least look at non-related build issues.
I don't have strong opinion on whether we should switch for Linaro builds, but would like to see stronger motivation than "it might be slightly faster" ;-). There're in particular bunch of ideas how to make android-build quicker, but going for them w/o actual benchmarking might be waste of time or lead to adverse effects...
ttyl bero
On Thu, Aug 11, 2011 at 2:29 AM, Bernhard Rosenkranzer bernhard.rosenkranzer@linaro.org wrote:
Hi, while working on some improvements, I noticed that our Android toolchain binaries are built as 32-bit x86. Is there any reason for this (other than "we inherited it from AOSP")?
While it doesn't matter much, it doesn't make much sense to me - Android can't currently be built on 32-bit machines (so it's not about having one binary that will work for mostly everyone - but I suspect that's exactly where it started back in the times of Android 1.0), so why introduce dependencies on a 32-bit libc and slow things down slightly?
If nobody complains, I'll remove the "-m32" flag from the Android toolchain builds - let's see how much we can speed up the build process itself without putting any real work into it...
I'd leave it as 32 bit. This gives you a single binary toolchain that can run on 32 bit and 64 bit hosts, no matter what host it was built on.
-- Michael
On 10 August 2011 14:44, Michael Hope michael.hope@linaro.org wrote:
On Thu, Aug 11, 2011 at 2:29 AM, Bernhard Rosenkranzer bernhard.rosenkranzer@linaro.org wrote:
Hi, while working on some improvements, I noticed that our Android toolchain binaries are built as 32-bit x86. Is there any reason for this (other than "we inherited it from AOSP")?
While it doesn't matter much, it doesn't make much sense to me - Android can't currently be built on 32-bit machines (so it's not about having one binary that will work for mostly everyone - but I suspect that's exactly where it started back in the times of Android 1.0), so why introduce dependencies on a 32-bit libc and slow things down slightly?
If nobody complains, I'll remove the "-m32" flag from the Android toolchain builds - let's see how much we can speed up the build process itself without putting any real work into it...
I'd leave it as 32 bit. This gives you a single binary toolchain that can run on 32 bit and 64 bit hosts, no matter what host it was built on.
I agree with Michael. That's a little more deviation than we should introduce. I think creating an investigation BP for it for 11.09 would be a good idea though.
-Zach
-- Michael
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On 10 August 2011 12:44, Michael Hope michael.hope@linaro.org wrote:
I'd leave it as 32 bit. This gives you a single binary toolchain that can run on 32 bit and 64 bit hosts, no matter what host it was built on.
If it actually builds on 32 bit hosts, I agree -- but in that case we should patch out the fact that the build process aborts saying you need a 64 bit machine when trying to do a build on a 32 bit host.
ttyl bero
-
Alexander Sack -
Bernhard Rosenkranzer -
Michael Hope -
Paul Sokolovsky -
Vladimir Pantelic -
Zach Pfeffer