Fix build of host&target destination products with --static-swift-stdlib
#7695
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
kateinoigakukun
force-pushed
the
katei/fix-exe-prod-plugin-static
branch
from
18f5ebb to
b2fd9a4
Compare
|
@swift-ci test |
xedin
reviewed
Jun 21, 2024
|
@swift-ci test |
|
@swift-ci test |
|
@swift-ci test Windows |
kateinoigakukun
requested review from
bnbarham,
MaxDesiatov,
jakepetroules and
francescomikulis
as code owners
|
@swift-ci test |
…dlib` Given the following conditions: - `--static-swift-stdlib` is enabled (it only affects "target" destination products, "host" destination products are always dynamic) - the building subset contains both "host" and "target" destination products derived from the same product. - the product imports `Foundation` (that has private dependency libs) then the build randomly failed due to the race condition of the Objects.LinkFileList creation. This commit fixes the issue by distinguishing the temporary link file list response file name by the `-tool` suffix.
This is usually the case when building with some of build-presets without `build-swift-static-stdlib` option.
kateinoigakukun
force-pushed
the
katei/fix-exe-prod-plugin-static
branch
from
80bf108 to
b7b1f8e
Compare
|
@swift-ci test |
|
@swift-ci test Windows |
MaxDesiatov
approved these changes
Jun 23, 2024
kateinoigakukun
added a commit
that referenced
this pull request
Jun 24, 2024
…ce (#7698) Add debug assertion to avoid llbuild command name conflicts. Depends on #7695 ### Motivation: One of the reasons we couldn't reveal #7695 issue for long time (at least past 2 releases) is that we overlooked name conflicts on `addWriteLinkFileListCommand`. Looking into the manifest builder, some of the commands also forgot to assert name conflicts, so it was error-prone. ### Modifications: Add a convenience method to perform assertions consistently ### Result: NFC for release build. Just add debug assertions
MaxDesiatov
pushed a commit
that referenced
this pull request
Jul 2, 2024
…dlib` (#7695) ### Motivation: Given the following conditions: - `--static-swift-stdlib` is enabled (it only affects "target" destination products, "host" destination products are always dynamic) - the building subset contains both "host" and "target" destination products derived from the same product. - the product imports `Foundation` (that has private dependency libs) then the build randomly failed due to the race condition of the Objects.LinkFileList creation. Reproducible project https://github.com/kateinoigakukun/swift-autolink-issue-repro ### Modifications: This commit fixes the issue by distinguishing the temporary link file list response file name by the `-tool` suffix. I think it would be better to add assertions in `LLBuildManifest` to avoid such unintentional target overwrites later. ### Result: Fix the build for the above case. (cherry picked from commit e858647)
MaxDesiatov
added a commit
that referenced
this pull request
Jul 2, 2024
Cherry-pick of #7695. **Explanation**: Given the following conditions: - `--static-swift-stdlib` is enabled (it only affects "target" destination products, "host" destination products are always dynamic) - the building subset contains both "host" and "target" destination products derived from the same product. - the product imports `Foundation` (that has private dependency libs) then the build randomly failed due to the race condition of the `Objects.LinkFileList` creation. Reproducible project: https://github.com/kateinoigakukun/swift-autolink-issue-repro **Scope**: isolated to packages with plugins **Risk**: low, the change was incubated on `main` for a few weeks now **Testing**: Added a new automated test case **Issue**: N/A **Reviewer**: @MaxDesiatov Co-authored-by: Yuta Saito <[email protected]>
norio-nomura
added a commit
to norio-nomura/docker-swiftlint
that referenced
this pull request
Jul 10, 2024
Avoid link error fixed in swiftlang/swift-package-manager#7695
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Motivation:
Given the following conditions:
--static-swift-stdlibis enabled (it only affects "target" destination products, "host" destination products are always dynamic)Foundation(that has private dependency libs)then the build randomly failed due to the race condition of the Objects.LinkFileList creation.
Reproducible project https://github.com/kateinoigakukun/swift-autolink-issue-repro
Modifications:
This commit fixes the issue by distinguishing the temporary link file list response file name by the
-toolsuffix.I think it would be better to add assertions in
LLBuildManifestto avoid such unintentional target overwrites later.Result:
Fix the build for the above case.