Skip to content
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

Build fails with the unsafe flags error #6

Closed
MaxDesiatov opened this issue May 5, 2020 · 3 comments · Fixed by #91
Closed

Build fails with the unsafe flags error #6

MaxDesiatov opened this issue May 5, 2020 · 3 comments · Fixed by #91
Labels
help wanted Extra attention is needed

Comments

@MaxDesiatov
Copy link
Contributor

I have a very trivial app here that depends on JavaScriptKit, but it fails to build with this error:

% swift build --triple wasm32-unknown-wasi                                     
error: the target 'JavaScriptKit' in product 'JavaScriptKit' contains unsafe build flags
% swiftenv version
wasm-DEVELOPMENT-SNAPSHOT-2020-05-02-a (set by /Users/maxd/Documents/carton/TestApp/.swift-version)
% which swift
/Users/maxd/.swiftenv/shims/swift
% swift --version
Swift version 5.3-dev (LLVM 11086900c5, Swift 52a06ad8f3)
Target: x86_64-apple-darwin19.4.0
@kateinoigakukun
Copy link
Member

Yes, you can't use a tag to specify a fixed revision due to unsafe flags.
So you need to specify a commit hash to fix revision like here

But in the long run, we need to support these flags safely in SwiftPM.

MaxDesiatov added a commit to TokamakUI/Tokamak that referenced this issue Aug 5, 2020
These SwiftWasm snapshots should be more stable in general and also have a workaround for swiftwasm/JavaScriptKit#6 included. They still use the old metadata layout, so Runtime and OpenCombine dependencies had to be updated in `Package.swift` for `@ObservableObject` to work with these snapshots.
MaxDesiatov added a commit to TokamakUI/Tokamak that referenced this issue Aug 6, 2020
* Use the latest 5.3 snapshot in `.swift-version`

These SwiftWasm snapshots should be more stable in general and also have a workaround for swiftwasm/JavaScriptKit#6 included. They still use the old metadata layout, so Runtime and OpenCombine dependencies had to be updated in `Package.swift` for `@ObservableObject` to work with these snapshots.

* Fix linter warning
@MaxDesiatov
Copy link
Contributor Author

MaxDesiatov commented Sep 24, 2020

I think this becomes a higher priority as it prevents any projects that depend on JavaScriptKit from being built for any platform other than WASI. For example, it's currently blocking TokamakUI/Tokamak#276.

The big problem is that it may require changes to the package manifest API, such as new safe linker settings. Any new settings won't be available on non-WASI platforms until the next version of Swift is released. If we add new linker settings, they definitely need to land upstream before the next version is branched off, but I think we also need to find some workaround in the meantime.

@MaxDesiatov MaxDesiatov added the help wanted Extra attention is needed label Sep 24, 2020
@MaxDesiatov
Copy link
Contributor Author

MaxDesiatov commented Oct 2, 2020

Here's a possible solution that I proposed in the #webassembly channel of SwiftPM Slack:

  1. For SwiftWasm 5.3 we could hardcode the flags and apply them in our forked SwiftPM if target/product name is JavaScriptKit. We then remove unsafe flags from Package.swift in JavaScriptKit as our forked SwiftPM would know how to build it anyway. We already have an ugly hardcoded check in our fork to allow unsafe flags in JavaScriptKit anyway. This would be a temporary fix only applicable to 5.3 snapshots.
  2. For future versions of Swift either Finish SE‐0226 (Ignore Unused Products) swiftlang/swift-package-manager#2749 resolves the issue, or we need to submit more PRs upstream that allow specifying export linker flags safely with new linkerSettings cases in Package.swift.

Yuta noted that:

If we have to update linker flag after the 5.3 toolchain will be released, we have to modify the SwiftPM and release a new patched version.

My counterargument is that upstream Swift for Linux has monthly patch releases anyway. So we'd expect 5.3.1 in October/November, 5.3.2 in December etc. I think we'd probably want our SwiftWasm patch releases for 5.3 to follow that schedule too.

Would JavaScriptKit change linker flags more frequently than once a month? If not, that would be an acceptable workaround until the next version of Swift is released. I hope we'll see Swift 5.4 or whatever the next version will be (maybe even Swift 6.0?) early next year. At least that was the upstream schedule recently: at least two minor releases a year, and patch releases every month for Linux (and now for Windows I guess)

So we only need to live with this workaround until early next year if all goes well 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants