With high enough number of jobs (think of distcc) and large enough objects (LLVM), the post-install stripping can be real OOM-killer. I think the dangers of that much outweigh the benefits of doing strip in parallel.
I guess we need a new configuration variable to control things like this, considering that distcc basically renders MAKEOPTS useless for this purpose.
removing parallel support from prepstrip is a non-starter. it was implemented precisely because it was a significant bottleneck. conversely, this is the first time i've heard of running into resource limits (with the code being 3 years old at this point). i don't see why it's specific to stripping though ... surely any process that uses a lot of memory and in parallel (like linking a lot of large objects) would cause the same failure on a resource constrained system.
A POSIX / GNU make jobserver (bug 692576) can help keep things like this under control. There's a proposal for golang to similarly parse and use MAKEFLAGS to allocate jobs in https://github.com/golang/go/issues/36868.
