Command to be executed prints in two separate parts when compiling binaries.

[ta0kira]

For example, when compilation of example/regex gets to RegexDemo, the clang++ command prints up until /tmp/zmain_??????.cpp, stops for a few seconds, and then prints the rest of the .o files. I can't tell if this is because gathering the .o deps takes a while or because the output is buffered. Flushing and strict evaluation in executeProcess didn't fix it.

[ta0kira]

It's clear from looking at the process table that the hang is with zeolite and not with clang++. As far as I can tell, it gets substantially worse the more categories a binary depends on, but does not affect compiling individual sources. This probably means that it's related to resolving object dependencies.

I know that getObjectFileResolver was not designed to be efficient, but maybe it has some extreme inefficiency that can be fixed.

[ta0kira]

It looks like an accidental part of this fix was no longer uniquing .a files. .a files were the main reason for having such an inefficient algorithm in the first place, but it turns out it works just fine to specify the same .a multiple times.