Skip to content

[Build] Repair the build for non-static-only static stdlib builds #73474

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

kateinoigakukun
Copy link
Member

@kateinoigakukun kateinoigakukun commented May 7, 2024

When SWIFT_BUILD_STATIC_STDLIB=ON, SWIFT_BUILD_DYNAMIC_STDLIB=OFF, and the sdk being built is not a static-only (e.g. WASI), the build fails due to duplicate custom command rules against the same output path. In the case of WASI, the static archive should be copied into lib/swift by the first lipo target, and then the second lipo target should copy it into lib/swift_static.

CMake Error at cmake/modules/SwiftAddCustomCommandTarget.cmake:144 (add_custom_command):
  Attempt to add a custom rule to output

    /home/build-user/build/buildbot_linux/wasmstdlib-linux-x86_64/lib/swift_static/wasi/libswiftCore.a.rule

  which already has a custom rule.
Call Stack (most recent call first):
  stdlib/cmake/modules/AddSwiftStdlib.cmake:673 (add_custom_command_target)
  stdlib/cmake/modules/AddSwiftStdlib.cmake:2657 (_add_swift_lipo_target)
  stdlib/public/core/CMakeLists.txt:401 (add_swift_target_library)

https://ci.swift.org/job/oss-swift-pr-test-crosscompile-wasm-ubuntu-20_04/585/console

When SWIFT_BUILD_STATIC_STDLIB=ON, SWIFT_BUILD_DYNAMIC_STDLIB=OFF, and
the sdk being built is not a static-only (e.g. WASI), the build fails
due to duplicate custom command rules against the same output path.
In the case of WASI, the static archive should be copied into lib/swift
by the first lipo target, and then the second lipo target should copy it
into lib/swift_static.

```
CMake Error at cmake/modules/SwiftAddCustomCommandTarget.cmake:144 (add_custom_command):
  Attempt to add a custom rule to output

    /home/build-user/build/buildbot_linux/wasmstdlib-linux-x86_64/lib/swift_static/wasi/libswiftCore.a.rule

  which already has a custom rule.
Call Stack (most recent call first):
  stdlib/cmake/modules/AddSwiftStdlib.cmake:673 (add_custom_command_target)
  stdlib/cmake/modules/AddSwiftStdlib.cmake:2657 (_add_swift_lipo_target)
  stdlib/public/core/CMakeLists.txt:401 (add_swift_target_library)
```
@kateinoigakukun kateinoigakukun requested a review from al45tair May 7, 2024 07:41
@kateinoigakukun
Copy link
Member Author

@swift-ci test WebAssembly

@kateinoigakukun
Copy link
Member Author

@swift-ci smoke test

@al45tair
Copy link
Contributor

al45tair commented May 7, 2024

Thanks for this; I think this also broke the embedded SDK :-(

@kateinoigakukun
Copy link
Member Author

Wasm CI job failed but the CMake issue itself seems resolved

/home/build-user/swift-nightly-install/usr/bin/swiftc: symbol lookup error: /home/build-user/build/buildbot_linux/earlyswiftdriver-linux-x86_64/release/dependencies/swift-tools-support-core/lib/libTSCBasic.so: undefined symbol: $s8Dispatch0A5QueueC5async5group3qos5flags7executeyAA0A5GroupCSg_AA0A3QoSVAA0A13WorkItemFlagsVyyXBtF

@kateinoigakukun kateinoigakukun marked this pull request as ready for review May 7, 2024 09:56
@kateinoigakukun kateinoigakukun requested a review from a team as a code owner May 7, 2024 09:56
@al45tair
Copy link
Contributor

al45tair commented May 7, 2024

Let's just merge this; it fixes a problem on macOS (specifically the embedded build) that for some reason I didn't spot before (I probably ran a smoke test instead of a full test, which was a mistake).

@al45tair al45tair merged commit cd2bb3d into swiftlang:main May 7, 2024
3 of 4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants