Fixed xclibtool not accounting the artifacts retrieved from cache in certain scenarios. #221
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Aug 2, 2023
polac24
approved these changes
Aug 2, 2023
Collaborator
polac24
left a comment
There was a problem hiding this comment.
Oh, thanks. Indeed, feeding the inputLibraries is too liberal and probably we should find a better way for identifying valid archive/binary.
This change is a temp workaround, we can apply a valid fix in a follow-up PR.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.