I just tested the install instructions on the macOS 11.1 with zsh and it appears to work as described.
In your error messages, those paths look wrong: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h For some reason, emcc seems to pick up native macOS CRT headers instead of emscripten's headers. Also, on my system, this path doesn't exist. There's a /Library/Developer/CommandLineTools/ directory, but below that there's no SDKs directory (in somewhat recent Xcode versions the system headers have moved to /Applications/Xcode.app/Contents/Developer/...), "xcrun --show-sdk-path" should show where the Apple clang compiler is expecting the native system headers, but that shouldn't be relevant for emscripten. So the question remains, why does emscripten use the wrong headers? No idea unfortunately :) But you can get emcc (and the system's native clang) to spit out a lot of useful information (for instance the header search paths): > emcc -E -v -x c /dev/null E.g. on my system this yields (among others): ... ignoring nonexistent directory "/Users/floh/scratch/emsdk/upstream/emscripten/cache/wasm/include" ignoring nonexistent directory "/include/wasm32-emscripten" ignoring nonexistent directory "/include" #include "..." search starts here: #include <...> search starts here: /Users/floh/scratch/emsdk/upstream/emscripten/system/include/SDL /Users/floh/scratch/emsdk/upstream/emscripten/system/include/compat /Users/floh/scratch/emsdk/upstream/emscripten/system/include /Users/floh/scratch/emsdk/upstream/emscripten/system/include/libc /Users/floh/scratch/emsdk/upstream/emscripten/system/lib/libc/musl/arch/emscripten /Users/floh/scratch/emsdk/upstream/emscripten/system/local/include /Users/floh/scratch/emsdk/upstream/emscripten/system/include/SSE /Users/floh/scratch/emsdk/upstream/emscripten/system/include/neon /Users/floh/scratch/emsdk/upstream/emscripten/system/lib/compiler-rt/include /Users/floh/scratch/emsdk/upstream/emscripten/system/lib/libunwind/include /Users/floh/scratch/emsdk/upstream/lib/clang/12.0.0/include End of search list. ... ...while the system clang spits out: ... #include "..." search starts here: #include <...> search starts here: /usr/local/include /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/12.0.0/include /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory) End of search list. ... Cheers, -Floh. On Tuesday, 24 November 2020 at 17:45:09 UTC+1 [email protected] wrote: > I installed emscripten using the standard instructions as per > https://emscripten.org/docs/getting_started/downloads.html#installation-instructions. > > Running `emcc -v` gave me no errors, and the following message: > ``` > (base) edbraun@gs66-lostcheme emscripten % emcc -v > emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) > 2.0.9 > clang version 12.0.0 > (/opt/s/w/ir/cache/git/chromium.googlesource.com-external-github.com-llvm-llvm--project > > 27e9f0f95ef7b144d008bc1cf1459dced6cb5842) > Target: x86_64-apple-darwin19.6.0 > Thread model: posix > InstalledDir: /Users/edbraun/software/emsdk/upstream/bin > shared:INFO: (Emscripten: Running sanity checks) > ``` > > I then moved on to the tutorial. Running `emcc tests/hello_world.c` gave > me errors however: > ``` > In file included from tests/hello_world.c:8: > In file included from > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:64: > In file included from > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:68: > > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:807:2: > > error: Unsupported architecture > #error Unsupported architecture > ^ > In file included from tests/hello_world.c:8: > In file included from > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:64: > In file included from > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:71: > > In file included from > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_types.h:27: > > In file included from > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types.h:33: > > > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/machine/_types.h:34:2: > > error: architecture not supported > #error architecture not supported > ^ > In file included from tests/hello_world.c:8: In file included from > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:64: > In file included from > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:71: > In file included from > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_types.h:27: > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types.h:55:9: > > error: unknown type name '__int64_t'; did you mean '__int128_t'? typedef > __int64_t __darwin_blkcnt_t; /* total blocks */ ^~~~~~~~~ __int128_t > note: '__int128_t' declared here > ``` > And so on. > > I'm having trouble debugging how the installation went wrong. Any tips? > I'm running macOS Catalina 10.15.7 with the zsh shell. > > Efrem Braun > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/ff970198-4393-4c67-bb36-7dfa9ef6a6can%40googlegroups.com.
