failure in compiling hello_world.cpp

[Efrem Braun]

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

[Floh]

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.

[Floh]

PS: my other thought was "maybe he forgot "./emsdk activate latest", but when trying this I get the following output from emcc:

emscripten ➤ ./emcc tests/hello_world.c                                                                      git:master

emcc: warning: LLVM version appears incorrect (seeing "6.0", expected "12.0") [-Wversion-check]

shared:CRITICAL: LLVM has not been built with the WebAssembly backend, llc reports:

===========================================================================

    js     - JavaScript (asm.js, emscripten) backend

    x86    - 32-bit X86: Pentium-Pro and above

    x86-64 - 64-bit X86: EM64T and AMD64

===========================================================================

emcc: error: failing sanity checks due to previous llvm failure

[Efrem Braun]

On my system, `scrun --show-sdk-path` does show `/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk` and looking at that folder it does appear to be correct.

`emcc -E -v -x c /dev/null` gives me the following, but I'm not able to figure out how it should help. Any other ideas?

```
(base) edbraun@gs66-lostcheme emscripten % emcc -E -v -x c /dev/null

shared:INFO: (Emscripten: Running sanity checks)

"/Users/edbraun/software/emsdk/upstream/bin/clang" -DEMSCRIPTEN -fignore-exceptions -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr -Xclang -isyste
m/Users/edbraun/software/emsdk/upstream/emscripten/system/include/SDL -target wasm32-unknown-emscripten -D__EMSCRIPTEN_major__=2 -D__EMSCRIPTEN_minor__=0 -D__EMSCRIPTEN_tiny__=9 -D_LIBCPP_ABI_VERS
ION=2 -Dunix -D__unix -D__unix__ -Werror=implicit-function-declaration -Xclang -nostdsysteminc -Xclang -isystem/Users/edbraun/software/emsdk/upstream/emscripten/system/include/compat -Xclang -isys
tem/Users/edbraun/software/emsdk/upstream/emscripten/system/include -Xclang -isystem/Users/edbraun/software/emsdk/upstream/emscripten/system/include/libc -Xclang -isystem/Users/edbraun/software/em
sdk/upstream/emscripten/system/lib/libc/musl/arch/emscripten -Xclang -isystem/Users/edbraun/software/emsdk/upstream/emscripten/system/local/include -Xclang -isystem/Users/edbraun/software/emsdk/up
stream/emscripten/system/include/SSE -Xclang -isystem/Users/edbraun/software/emsdk/upstream/emscripten/system/include/neon -Xclang -isystem/Users/edbraun/software/emsdk/upstream/emscripten/system/
lib/compiler-rt/include -Xclang -isystem/Users/edbraun/software/emsdk/upstream/emscripten/system/lib/libunwind/include -Xclang -isystem/Users/edbraun/software/emsdk/upstream/emscripten/cache/wasm/
include -E -v -x c /dev/null

clang version 12.0.0 (/opt/s/w/ir/cache/git/chromium.googlesource.com-external-github.com-llvm-llvm--project 27e9f0f95ef7b144d008bc1cf1459dced6cb5842)

Target: wasm32-unknown-emscripten

Thread model: posix
InstalledDir: /Users/edbraun/software/emsdk/upstream/bin

(in-process)
"/Users/edbraun/software/emsdk/upstream/bin/clang-12" -cc1 -triple wasm32-unknown-emscripten -E -disable-free -main-file-name null -mrelocation-model static -mframe-pointer=none -fno-rounding-mat
h -mconstructor-aliases -target-cpu generic -fvisibility hidden -debugger-tuning=gdb -target-linker-version 609 -v -resource-dir /Users/edbraun/software/emsdk/upstream/lib/clang/12.0.0 -D EMSCRIPT
EN -D __EMSCRIPTEN_major__=2 -D __EMSCRIPTEN_minor__=0 -D __EMSCRIPTEN_tiny__=9 -D _LIBCPP_ABI_VERSION=2 -D unix -D __unix -D __unix__ -I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/inc
lude -internal-isystem /Users/edbraun/software/emsdk/upstream/lib/clang/12.0.0/include -internal-isystem /include/wasm32-emscripten -internal-isystem /include -Werror=implicit-function-declaration
-fdebug-compilation-dir /Users/edbraun/software/emsdk/upstream/emscripten -ferror-limit 19 -fgnuc-version=4.2.1 -fignore-exceptions -fcolor-diagnostics -isystem/Users/edbraun/software/emsdk/upstr
eam/emscripten/system/include/SDL -nostdsysteminc -isystem/Users/edbraun/software/emsdk/upstream/emscripten/system/include/compat -isystem/Users/edbraun/software/emsdk/upstream/emscripten/system/i
nclude -isystem/Users/edbraun/software/emsdk/upstream/emscripten/system/include/libc -isystem/Users/edbraun/software/emsdk/upstream/emscripten/system/lib/libc/musl/arch/emscripten -isystem/Users/e
dbraun/software/emsdk/upstream/emscripten/system/local/include -isystem/Users/edbraun/software/emsdk/upstream/emscripten/system/include/SSE -isystem/Users/edbraun/software/emsdk/upstream/emscripte
n/system/include/neon -isystem/Users/edbraun/software/emsdk/upstream/emscripten/system/lib/compiler-rt/include -isystem/Users/edbraun/software/emsdk/upstream/emscripten/system/lib/libunwind/includ
e -isystem/Users/edbraun/software/emsdk/upstream/emscripten/cache/wasm/include -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr -o - -x c /dev/null
clang -cc1 version 12.0.0 based upon LLVM 12.0.0git default target x86_64-apple-darwin19.6.0

ignoring nonexistent directory "/include/wasm32-emscripten"
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
/Users/edbraun/software/emsdk/upstream/emscripten/system/include/SDL
/Users/edbraun/software/emsdk/upstream/emscripten/system/include/compat
/Users/edbraun/software/emsdk/upstream/emscripten/system/include
/Users/edbraun/software/emsdk/upstream/emscripten/system/include/libc
/Users/edbraun/software/emsdk/upstream/emscripten/system/lib/libc/musl/arch/emscripten
/Users/edbraun/software/emsdk/upstream/emscripten/system/local/include
/Users/edbraun/software/emsdk/upstream/emscripten/system/include/SSE
/Users/edbraun/software/emsdk/upstream/emscripten/system/include/neon
/Users/edbraun/software/emsdk/upstream/emscripten/system/lib/compiler-rt/include
/Users/edbraun/software/emsdk/upstream/emscripten/system/lib/libunwind/include
/Users/edbraun/software/emsdk/upstream/emscripten/cache/wasm/include
/Users/edbraun/software/emsdk/upstream/lib/clang/12.0.0/include
End of search list.
# 1 "/dev/null"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 311 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "/dev/null" 2
```

 

Efrem Braun

[gianluca torta]

have you run emsdk_env.sh?

Gianluca

[Efrem Braun]

Yes, I followed the instructions given here: https://emscripten.org/docs/getting_started/downloads.html#sdk-download-and-install:

git clone https://github.com/emscripten-core/emsdk.git
cd emsdk
./emsdk install latest
./emsdk activate latest
source ./emsdk_env.sh

I just deleted the installation and tried those 5 steps again. I immediately ran `emcc -E -v -x c /dev/null`, and it again showed `/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include` as the first directory in the #include search path.

Efrem Braun

--
You received this message because you are subscribed to a topic in the Google Groups "emscripten-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/emscripten-discuss/2Ot0ZQoK9is/unsubscribe.
To unsubscribe from this group and all its topics, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/c319d3be-35b6-488d-8296-be3251529e77n%40googlegroups.com.

[Efrem Braun]

Changing the shell to bash and redoing the installation gave the same results, so it's not the zsh shell.

It's really strange that `-I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/inc` is being passed to clang, as shown by `emcc -E -v -x c /dev/null`. That does seem to be the culprit, but I don't know why that's happening or how to change it.

Efrem Braun

[Floh]

Yeah, the first include here is the problem (/Library/Developer/...). The question is how this is getting in there...

#include "..." search starts here:
#include <...> search starts here:

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
/Users/edbraun/software/emsdk/upstream/emscripten/system/include/SDL
/Users/edbraun/software/emsdk/upstream/emscripten/system/include/compat

I don't know if clang/emcc has any hidden feature to get header search paths from anywhere else than the command line (like an environment variable maybe?), I tried googling for that but haven't found anything.

[Floh]

Complete shot in the dark, but does this show anything:

env | grep CommandLineTools

...basically checking if that include path shows up in any environment variable...

[Efrem Braun]

That's it! `env | grep CommandLineTools` showed me `CPATH=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include`. I then ran `export CPATH=''`, and then I compiled hello_world.c without any problems. Apparently I was setting the CPATH environment variable in my .zprofile.

Thanks so much everyone!

Efrem Braun

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/c375d3c0-dd42-4aa3-a469-468abec6be40n%40googlegroups.com.

[gianluca torta]

uhm... to me it looks like a bug, albeit a small one?

Gianluca

[Efrem Braun]

Well, what I have is very common among Catalina users (see https://apple.stackexchange.com/questions/372032/usr-include-missing-on-macos-catalina-with-xcode-11, where it's advised to put `export CPATH=`xcrun --show-sdk-path`/usr/include` in your .zshprofile/.zshrc file, which is exactly what I was doing.

So I don't know if I would call it a bug, but putting some kind of message somewhere for Catalina users about this might be a good idea.

Efrem Braun

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/6f0bc68e-756b-4dcd-a5cf-f0df58baf234n%40googlegroups.com.

[Floh]

Oh interesting and TIL, I didn't know that CPATH thing. Maybe emcc should somehow ignore CPATH, it sounds like it could happen to more people, and it's a very obscure sort of problem.

[Alon Zakai]

Interesting...

I'm not sure we can ignore CPATH, as in principle someone might use it intentionally, and put a path to valid emscripten contents there.

On the other hand if this is common on some OSes then it does seem like something we should do something about, even if only warn.

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 emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/473cc9ad-e872-43a9-9bf8-a8b66c99a771n%40googlegroups.com.

[gianluca torta]

in emcc.py I saw this when I was looking at this problem earlier

(lines 2581>> in my version)

        diagnostics.warning(
            'absolute-paths', '-I or -L of an absolute path "' + arg +
            '" encountered. If this is to a local system header/library, it may '
            'cause problems (local system files make sense for compiling natively '
            'on your system, but not necessarily to JavaScript).')

maybe the same should be applied here?

Gianluca

[Sam Clegg]

On Wed, Nov 25, 2020 at 11:31 AM gianluca torta <giat...@gmail.com> wrote:

in emcc.py I saw this when I was looking at this problem earlier

(lines 2581>> in my version)

        diagnostics.warning(
            'absolute-paths', '-I or -L of an absolute path "' + arg +
            '" encountered. If this is to a local system header/library, it may '
            'cause problems (local system files make sense for compiling natively '
            'on your system, but not necessarily to JavaScript).')

maybe the same should be applied here?

Yes that sounds reasonable.  We should treat entries in $CPATH the same the `-I` flags. 

If anyone feels like making a PR this seems like the right approach.

cheers,

sam

 

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/443b8133-9f4c-4a93-8572-9222747fe9ccn%40googlegroups.com.