Fix windows SDK builds #126

vvuk · 2020-04-19T06:28:36Z

Tweak the Makefile to make things work under Windows. The assumption is that this will run under msys2 bash (i.e. git-bash), which seems to be where github CI will run it anyway. Removing that assumption would probably require not using Makefiles, and isn't really worth it.

There's also a "trigger on push to all branches" workflow thing in here that I can nuke before this lands, I needed it to test (and my final run is still running).

Fixes #39

vvuk · 2020-04-19T18:21:26Z

Fixed tar_from_installation to not hardcode the source build dir.

The final build on Windows is going to be much larger, because until recently, Windows didn't really support a useful form of symlinks so the llvm build process (probably due to cmake) just makes multiple copies to clang++, clang-cpp, clang-cl etc. This can be fixed on recent versions of Windows with developer mode enabled, but I don't know of any archive format that knows how to deal with this on Windows (ideally you could but symlinks in the archive, and it would create symlinks if they're supported otherwise just create a copy of the file).

sbc100

This is awesome! Thanks for working on it.

.github/workflows/main.yml

Makefile

tar_from_installation.sh

Makefile

sbc100 · 2020-04-19T22:07:37Z

Fixed tar_from_installation to not hardcode the source build dir.

The final build on Windows is going to be much larger, because until recently, Windows didn't really support a useful form of symlinks so the llvm build process (probably due to cmake) just makes multiple copies to clang++, clang-cpp, clang-cl etc. This can be fixed on recent versions of Windows with developer mode enabled, but I don't know of any archive format that knows how to deal with this on Windows (ideally you could but symlinks in the archive, and it would create symlinks if they're supported otherwise just create a copy of the file).

I think its fine if the windows build is larger in roughly the same way the a normal clang/llvm distribution is larger. In other words we shouldn't be trying to fix that problem downstream if they haven't yet addressed it upstream.

vvuk · 2020-04-19T22:34:04Z

So the only issue is that my last CI run died strangely (extra newlines added to log snippet):

-- Install configuration: "RelWithDebInfo"
-- Installing: C:/wasi-sdk/lib/clang/10.0.0/lib/wasi/libclang_rt.builtins-wasm32.a
"c:/wasi-sdk/bin/clang" -O2 -DNDEBUG --target=wasm32-wasi -fno-trapping-math -mthread-model single --sysroot="c:/wasi-sdk/share/wasi-sysroot" -Id:/a/wasi-sdk/wasi-sdk/src/wasi-libc/libc-bottom-half/headers/private -Id:/a/wasi-sdk/wasi-sdk/src/wasi-libc/libc-bottom-half/cloudlibc/src/include -Id:/a/wasi-sdk/wasi-sdk/src/wasi-libc/libc-bottom-half/cloudlibc/src -MD -MP -o d:/a/wasi-sdk/wasi-sdk/src/wasi-libc/build/libc-bottom-half/cloudlibc/src/libc/fcntl/posix_fallocate.o -c d:/a/wasi-sdk/wasi-sdk/src/wasi-libc/libc-bottom-half/cloudlibc/src/libc/fcntl/posix_fallocate.c

# Install clang-provided headers.
cp -R d:/a/wasi-sdk/wasi-sdk/build/llvm/lib/clang c:/wasi-sdk/lib/

"c:/wasi-sdk/bin/clang" -O2 -DNDEBUG --target=wasm32-wasi -fno-trapping-math -mthread-model single --sysroot="c:/wasi-sdk/share/wasi-sysroot" -Id:/a/wasi-sdk/wasi-sdk/src/wasi-libc/libc-bottom-half/headers/private -Id:/a/wasi-sdk/wasi-sdk/src/wasi-libc/libc-bottom-half/cloudlibc/src/include -Id:/a/wasi-sdk/wasi-sdk/src/wasi-libc/libc-bottom-half/cloudlibc/src -MD -MP -o d:/a/wasi-sdk/wasi-sdk/src/wasi-libc/build/libc-bottom-half/cloudlibc/src/libc/poll/poll.o -c d:/a/wasi-sdk/wasi-sdk/src/wasi-libc/libc-bottom-half/cloudlibc/src/libc/poll/poll.c

"c:/wasi-sdk/bin/clang" -O2 -DNDEBUG --target=wasm32-wasi -fno-trapping-math -mthread-model single --sysroot="c:/wasi-sdk/share/wasi-sysroot" -Id:/a/wasi-sdk/wasi-sdk/src/wasi-libc/libc-bottom-half/headers/private -Id:/a/wasi-sdk/wasi-sdk/src/wasi-libc/libc-bottom-half/cloudlibc/src/include -Id:/a/wasi-sdk/wasi-sdk/src/wasi-libc/libc-bottom-half/cloudlibc/src -MD -MP -o d:/a/wasi-sdk/wasi-sdk/src/wasi-libc/build/libc-bottom-half/cloudlibc/src/libc/sched/sched_yield.o -c d:/a/wasi-sdk/wasi-sdk/src/wasi-libc/libc-bottom-half/cloudlibc/src/libc/sched/sched_yield.c

cp: cannot create regular file 'c:/wasi-sdk/lib/clang/10.0.0/include/stdint.h': Permission denied
mingw32-make: *** [Makefile:88: build/compiler-rt.BUILT] Error 1
mingw32-make: *** Waiting for unfinished jobs....

...

/usr/bin/sh: c:/wasi-sdk/bin/clang: No such file or directory
/usr/bin/sh: c:/wasi-sdk/bin/clang: No such file or directory
mingw32-make[1]: *** [Makefile:364: d:/a/wasi-sdk/wasi-sdk/src/wasi-libc/build/libc-bottom-half/cloudlibc/src/libc/stdio/renameat.o] Error 127
mingw32-make[1]: *** Waiting for unfinished jobs....
mingw32-make[1]: *** [Makefile:364: d:/a/wasi-sdk/wasi-sdk/src/wasi-libc/build/libc-bottom-half/cloudlibc/src/libc/sys/ioctl/ioctl.o] Error 127

I have no idea what happened here. It's almost as if c:/wasi-sdk just .. went away or otherwise got screwed? Each job time limit is 6 hours, so we're nowhere near that. Let's see what happens with the new one.

vvuk · 2020-04-19T22:35:49Z

Let's try without -j4. All that stuff in potentially parallel looks strange.

vvuk · 2020-04-19T22:38:03Z

Oh wait, that broken CI run was I think one of my own. This one succeeded! https://github.com/WebAssembly/wasi-sdk/actions/runs/82251119

(it was for the "trigger on push" commit that I just nuked)

pchickey · 2020-04-20T15:57:12Z

This is awesome, thank you for working on it!

Do you mind getting rid of the -j4 permanently? It has frequently tripped me up as well when debugging, and ninja does all of the useful parallelism.

vvuk · 2020-04-20T17:36:04Z

Done!

pchickey

Thanks so much! Will merge as soon as CI completes.

sbc100 · 2020-04-20T18:28:23Z

I think the one place there the top level -j flag is useful was the $(MAKE) command for building wasi-libc.

This change would cause the build of wasi-libc to only use a single core. Maybe thats fine since it so small compared to llvm? Maybe we should has a -j4 the make command used internally to build wasi-libc?

pchickey · 2020-04-20T20:56:44Z

Ah, i forgot about that, and you are correct. I'll merge this and make a PR restoring that -j4.

sbc100 · 2020-04-20T21:17:37Z

just looking that sizes, I wonder how mac manages to be so much smaller:

dist-macos-latest 42.3 MB
dist-ubuntu-latest 75.5 MB
dist-ubuntu-xenial 73.2 MB
dist-windows-latest 133 MB

vvuk · 2020-04-20T22:49:44Z

If you look at the build times with and without -j4:
ubuntu: with: 1h39m without: 1h40m
mac: with: 56m without: 56m

I'm not sure if it's doing much of anything, which makes sense because the the Makefile is largely serial. I'm guessing there's 1 or 2 steps that make decides it can parallelize, which causes problems because I /think/ it starts a build of some code that wants things like stddef.h before those things have actually finished copying over.

vvuk · 2020-04-20T22:52:22Z

Ah yeah -- compiler-rt and libc seem like they can run in parallel, and the end of compiler-rt does:

    cp -R $(ROOT_DIR)/build/llvm/lib/clang $(PREFIX)/lib/

which is going to overwrite files that clang is going to be reading from while libc is being built. It'll overwrite them with themselves so should be okay, but on Windows you can race on reading a file (permission denied) while it's being replaced, which matches the error I was seeing in CI.

sbc100 · 2020-04-20T22:56:09Z

I'm not suggesting we use -j4 on the top level make command, just on the inner libc make command

* Add an entrypoint for calling open that bypasses the varargs. * Add an entrypoint for calling openat that bypasses the varargs.

This brings in the following changes: f645f49 Update signal macros after upgrade to snapshot1 (WebAssembly#144) 8b3266d github actions: pin checkout action to v1 (WebAssembly#145) 410c660 Use constructor functions for optional init routines. (WebAssembly#142) fe13053 c header generation updated for reorganized witx ast (WebAssembly#139) cd74e1d Correct the version of WebAssembly#136 on master (WebAssembly#141) 446cb3f Wasi snapshot preview1 (WebAssembly#140) 54102f0 Ignore rights in libpreopen. (WebAssembly#129) 8c9e1c6 Make the `__original_main` definition weak, fixing -flto. (WebAssembly#138) cf81683 Optimize `fmin`, `fmax`, etc. (WebAssembly#120) deb8eae Don't pre-check capabilities in `openat`. (WebAssembly#130) ca9046d Use consistent style for wasi-libc C source files. (WebAssembly#131) 951cc3e Fix unintended recursion in __wasilibc_register_preopened_fd. (WebAssembly#133) 5216983 Avoid a `strdup` call in `__wasilibc_populate_libpreopen`. (WebAssembly#128) 70099d4 Don't link in libpreopen initialization code when it isn't needed. (WebAssembly#127) ec4549d Temporarily disable the use of `__heap_base`. (WebAssembly#132) a214f1c Use __heap_base by dlmalloc (WebAssembly#114) a94d2d0 Avoid varargs conventions when calling open (WebAssembly#126) 7fcc4f2 Revamp and simplify the libpreopen code. (WebAssembly#110) eb7230c Remove more unsupported headers. (WebAssembly#123)

vvuk added 4 commits April 18, 2020 23:07

Make build work on Windows

abb9002

re-enable windows build workflow

1bc45a3

fix make check

3307f2d

fix tar_from_installation.sh and dist target

2bde8b9

vvuk force-pushed the windows-build branch from aad8c06 to 114f35b Compare April 19, 2020 18:16

sbc100 reviewed Apr 19, 2020

View reviewed changes

Review fixups

a1be37b

vvuk force-pushed the windows-build branch from 114f35b to a1be37b Compare April 19, 2020 22:30

No -j4 on Windows

305fff0

Get rid of -j4 everywhere in Makefile

8a6ddee

pchickey approved these changes Apr 20, 2020

View reviewed changes

pchickey merged commit 6c59b64 into WebAssembly:master Apr 20, 2020

pchickey mentioned this pull request Apr 20, 2020

makefile: recursive make to wasi-libc should have -j4 #128

Closed

pchickey mentioned this pull request Jun 1, 2020

Cut release 11 #139

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix windows SDK builds #126

Fix windows SDK builds #126

vvuk commented Apr 19, 2020

vvuk commented Apr 19, 2020

sbc100 left a comment

sbc100 commented Apr 19, 2020

vvuk commented Apr 19, 2020

vvuk commented Apr 19, 2020

vvuk commented Apr 19, 2020

pchickey commented Apr 20, 2020 •

edited

Loading

vvuk commented Apr 20, 2020

pchickey left a comment

sbc100 commented Apr 20, 2020

pchickey commented Apr 20, 2020

sbc100 commented Apr 20, 2020 •

edited

Loading

vvuk commented Apr 20, 2020

vvuk commented Apr 20, 2020

sbc100 commented Apr 20, 2020

Fix windows SDK builds #126

Fix windows SDK builds #126

Conversation

vvuk commented Apr 19, 2020

vvuk commented Apr 19, 2020

sbc100 left a comment

Choose a reason for hiding this comment

sbc100 commented Apr 19, 2020

vvuk commented Apr 19, 2020

vvuk commented Apr 19, 2020

vvuk commented Apr 19, 2020

pchickey commented Apr 20, 2020 • edited Loading

vvuk commented Apr 20, 2020

pchickey left a comment

Choose a reason for hiding this comment

sbc100 commented Apr 20, 2020

pchickey commented Apr 20, 2020

sbc100 commented Apr 20, 2020 • edited Loading

vvuk commented Apr 20, 2020

vvuk commented Apr 20, 2020

sbc100 commented Apr 20, 2020

pchickey commented Apr 20, 2020 •

edited

Loading

sbc100 commented Apr 20, 2020 •

edited

Loading