size_t redefinition error with --target=wasm on Windows

Hi all,

Just joined this dl, so apologies if this is not the right place for such a question. Please redirect me if appropriate.

I’ve been trying to use the new --target=wasm option on Windows, with the minimal codebase from the repo at https://github.com/PetterS/clang-wasm (which targets Linux). Whether I use clang++ or clang-cl (with what I believe to be the right options) I get an error re the MSVC headers trying to redefine size_t, e.g. as shown below:

C:\temp\clang-wasm>“C:\Program Files\LLVM\bin\clang++.exe” -c --target=wasm32 -Os -flto -nostdlib -fvisibility=hidden -std=c++14 -ffunction-sections -fdata-sections -fms-extensions -fms-compatibility -fms-compatibility-version=19.16.27026 -I “C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\include” -I “C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\ucrt” -D _M_IX86 -o library.o library.cpp

In file included from library.cpp:1:

In file included from C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\ucrt\memory.h:12:

In file included from C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\ucrt\corecrt_memory.h:13:

In file included from C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\ucrt\corecrt.h:10:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\include\vcruntime.h:184:30: error: typedef redefinition with different types (‘unsigned int’ vs ‘unsigned long’)

typedef unsigned int size_t;

^

Any ideas on this? Being a new feature I can’t find too many docs or examples, so I may be messing up something simple.

Using clang-cl I get similar errors. (And need to set the include directories and architecture (-D _M_IX86) explicitly to avoid other errors – which I though clang-cl should set automatically when running from the Developer Command Prompt). Without --target=wasm with similar (but valid .exe) code, I don’t see any errors.

You can see my build commands/flags with comments in my fork at https://github.com/billti/clang-wasm/blob/master/build.bat (using a bat file to keep it simple at this point).

Thanks,

  • Bill

Hello Bill,

Using MSVC x86 header files to compile for wasm32 isn’t currently a supported configuration. System header files are typically tied to a corresponding runtime library, so in addition to clang not supporting this yet, there’s no wasm32 version of the MSVC runtime libraries that you could link with even if it did compile.

The WASI project provides a set of header files that use can be used with clang’s wasm32 support, which may be useful here:

https://github.com/CraneStation/wasi-sysroot

An “SDK” which builds a clang and wasi-sysroot configured to be used together is here:

https://github.com/CraneStation/wasi-sdk

Dan

Thanks Dan.

I’m not trying to link to any runtime library implementation, just use the headers for the declarations. The definitions for the few runtime library APIs used are provided in the code. It’s a simple web app for demo purposes.

The build using the system headers appears to be working on Linux (I assume), being that’s what the code I forked targets. I’m guessing the MSVC C runtime headers aren’t compatible for this use however.

For now I just removed all the #includes for the standard runtime headers, and wrote a small common header for the declarations I need and included this in each .cpp file (see https://github.com/billti/clang-wasm/blob/master/nanolibc/libc.h), and this is compiling fine now on Windows with LLVM 8 with the build.bat script in the root, and the output works in Chrome.

My code does seem to have a bug, and stepping through the WAST representation in the browser tools is pain. Does the clang/wasm-ld toolchain support emitting sourcemaps at this point? (I couldn’t see any flags that looked like candidates)

The WASI stuff looks super-cool. I’d love to stay in the loop on it and play around as it develops. Is there somewhere to subscribe to keep up to date? (Or just watch the GitHub repos?).

Thanks,

  • Bill

Thanks Dan.

I’m not trying to link to any runtime library implementation, just use the headers for the declarations. The definitions for the few runtime library APIs used are provided in the code. It’s a simple web app for demo purposes.

The build using the system headers appears to be working on Linux (I assume), being that’s what the code I forked targets. I’m guessing the MSVC C runtime headers aren’t compatible for this use however.

It’s possible you may get things to work in simple cases. In general though, there are a lot of things that can go wrong if the libc header files you include don’t match the compiled libc that you link with, so it’s not something I recommend doing.

For now I just removed all the #includes for the standard runtime headers, and wrote a small common header for the declarations I need and included this in each .cpp file (see https://github.com/billti/clang-wasm/blob/master/nanolibc/libc.h), and this is compiling fine now on Windows with LLVM 8 with the build.bat script in the root, and the output works in Chrome.

My code does seem to have a bug, and stepping through the WAST representation in the browser tools is pain. Does the clang/wasm-ld toolchain support emitting sourcemaps at this point? (I couldn’t see any flags that looked like candidates)

There is some experimental work along these lines, but it’s still in progress.

The WASI stuff looks super-cool. I’d love to stay in the loop on it and play around as it develops. Is there somewhere to subscribe to keep up to date? (Or just watch the GitHub repos?).

Rigth now, watch the Github repos :-).

Dan