This should address the workaround for fat binaries stored instead of thinned build products, on CreateUniversalBinary step producing fat binary with duplicate symbols in certain scenarios.
Basically there are two bugs in calculation of libtool inputs, that in turn affect calculation of TARGET_TEMP_DIR, that in turn affects missing the cache in CreateUniversalBinary, that in turn breaks the workaround, making the "default" libtool merging two fat binaries (vs thin ones expected by default/generated without the cache), that results in duplicate symbols error on attempt to link with the result of the merge.
Leaving aside handling of -static, I'm not 100% sure, but I feel like any scenario that involves redirection from libtool to CreateUniversalBinary that is affected by 5741297, making xclibtool "always miss the cache" - so probably it's worth fixing it in general. Btw, I notice that ProcessInfo().arguments is probably misinterpreted (making executable name treated as an input) at least for lipo as well (I'm not sure about the effect though) - probably it's worth checking it in other places as well.
This should address the workaround for fat binaries stored instead of thinned build products, on CreateUniversalBinary step producing fat binary with duplicate symbols in certain scenarios.
Basically there are two bugs in calculation of libtool inputs, that in turn affect calculation of TARGET_TEMP_DIR, that in turn affects missing the cache in CreateUniversalBinary, that in turn breaks the workaround, making the "default" libtool merging two fat binaries (vs thin ones expected by default/generated without the cache), that results in duplicate symbols error on attempt to link with the result of the merge.
Leaving aside handling of
-static, I'm not 100% sure, but I feel like any scenario that involves redirection from libtool to CreateUniversalBinary that is affected by 5741297, making xclibtool "always miss the cache" - so probably it's worth fixing it in general. Btw, I notice that ProcessInfo().arguments is probably misinterpreted (making executable name treated as an input) at least for lipo as well (I'm not sure about the effect though) - probably it's worth checking it in other places as well.