For anyone who ends up with an "argument list too long" error when trying to build Android: run ulimit -s 9999999 first. The maximum command line size on Linux is a percentage of the stack size ulimit.
4
25
144
Conversation
I'm curious whether this is just an oversight in the build script. I recently ran into the "argument list too long" issue with my shell, and it was because I was using subshells instead of named pipes.
1
2
like android is pretty much the only build system i know where even just *starting* a build makes your system mostly unresponsive for the next 20 or so minutes
1
1
3
AOSP build system is ninja, and that's not my experience with it. It chooses the number of jobs based on the number of hardware threads by default rather than opting in, so if you're comparing to using 1 thread that's relevant. CPU cgroup + SCHED_BATCH helps with this in general.
2
That's a rather bad default if the limiting factor is going to be memory rather than cpu...
1
1
The limiting factor is definitely CPU for most workstations purchased to do this kind of compilation. Using a single job would definitely be a worse default. Hidden serialization enabled by default would also be pretty bad. Dev time is way more expensive than a good workstation.
2
llvm allows users to opt into running linking steps serially. by default it runs them like any other task
1
LLVM consists of very few, very large components vs. a drastically larger number of components varying quite a bit in size and compile options. CFI/LTO is currently only enabled for a certain subset too. It'd be a lot more complicated to come up with useful opt-in serialization.
In a production build (is_official_build = true, is_component_build = false, is_cfi = true, etc.), Chromium is literally a single binary built with LTO, so the build process is inherently very serial, with massive memory usage for 1 component being built for that a single job.