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.

Sign up for GitHub

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

Jump to bottom

Windows builds require libcc_s_seh-1.dll to be available #148

Closed
vvuk opened this issue Jun 16, 2020 · 4 comments · Fixed by #164
Closed

Windows builds require libcc_s_seh-1.dll to be available #148

vvuk opened this issue Jun 16, 2020 · 4 comments · Fixed by #164

Comments

@vvuk
Copy link
Contributor

vvuk commented Jun 16, 2020

The Windows Clang builds require libcc_s_seh-1.dll, which is present in the Git Bash environment (mingw based). This is unexpected; I'm not sure why this dependency is coming in to clang itself. We should fix this, as right now the generated wasi SDK for Windows only works if you have this DLL in your path from somewhere.

(I can take a look at some point, but if someone beats me to it please do)
@sbc100
Copy link
Member

sbc100 commented Jun 16, 2020 •
edited
Loading

Any idea on how to fix this welcome. Many of us who work on wasi-sdk don't use windows ourselves so its really up to windows users and contributors to keep this working.

@vvuk
Copy link
Contributor Author

vvuk commented Nov 16, 2020

The issue is this:

-- The C compiler identification is GNU 8.1.0
-- The CXX compiler identification is GNU 8.1.0
-- The ASM compiler identification is GNU
-- Found assembler: C:/ProgramData/chocolatey/bin/gcc.exe
...
-- Check for working C compiler: C:/ProgramData/chocolatey/bin/gcc.exe - skipped

Basically the image environment has some random gcc in it, and cmake picks this up by default. I believe the actions windows image should have VS in it which is what we want to use. Will try to wrangle the cmake setup.

@vvuk vvuk mentioned this issue Nov 17, 2020
Merged
kildom pushed a commit to kildom/clang-wasi-port that referenced this issue Jul 14, 2021
@sunfishcode
Avoid using cast expressions in WASI API constants. (WebAssembly#148)
dd010be 
Cast expressions aren't valid to use in some preprocessor constants, so
change the constants to use `UINT32_C` etc. instead of casts.

Fixes WebAssembly#146.
alexcrichton pushed a commit to alexcrichton/wasi-sdk that referenced this issue Apr 5, 2023
@sbc100
Update submodules and switch to llvm 9 branch (WebAssembly#102)
79d881c 
This change was mostly generated by changing the upstream llvm
branch to 9.x and running:

  $ git submodule update --remote

As well as switching the llvm 9 this change also bring in the
following wasi-libc changes:

  5933c20 fix macos filename, use https
  7c39519 CI: upgrade to llvm 9.0.0
  9ca5187 remove no-self-update workaround for windows azure
  9580a25 deprecate azure pipelines CI, build libc on GH Actions
  2c2fc9a Don't call `free` on paths which are about to call `_Exit`. (WebAssembly#161)
  c6f2c05 gen-headers: Generate assertions of layout from witx (WebAssembly#149)
  37c663f Correct minor typo in c_headers.rs (WebAssembly#166)
  12f5832 Convert more wasi-libc code to `//`-style comments. (WebAssembly#153)
  ec86d4d Improvements to wasi-headers tool (WebAssembly#160)
  1fad338 Fix environment variable init to exit successfully. (WebAssembly#159)
  a280fea Move math source files. (WebAssembly#151)
  dd010be Avoid using cast expressions in WASI API constants. (WebAssembly#148)

Fixes: WebAssembly#101
@ringoz
Copy link

ringoz commented Jul 20, 2024

the problem resurfaced in recent v23 release, probably after #429

@alexcrichton alexcrichton mentioned this issue Jul 22, 2024
Closed
@alexcrichton
Copy link
Collaborator

Thanks for the report! I've opened #454 to track that, and I'll work on investigating it over there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Build windows SDK with MSVC instead of gcc vvuk/wasi-sdk
4 participants
@alexcrichton @vvuk @sbc100 @ringoz