Build from source: bits/alltypes.h missing

[remoe]

After build all from source, i can't build a hello-world.cpp because of missing file: bits/alltypes.h:

emcc hello_world.c

In file included from hello_world.c:8:
In file included from emscripten-1.38.41\system\include\libcxx\stdio.h:108:
emscripten-1.38.41\system\include\libc\stdio.h:22:10: fatal error: cannot open file
      'emscripten-1.38.41\system\include\libc\bits/alltypes.h': permission denied
#include <bits/alltypes.h>
         ^

On the docs I've read that one don't need to build something:

https://emscripten.org/docs/building_from_source/index.html

But one need for example a file from:

https://github.com/emscripten-core/emscripten/blob/incoming/system/include/libc/alltypes.h.in

What one need to run to use this libs from source?

emcc -v
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 1.38.40
clang version 10.0.0 (https://github.com/llvm/llvm-project.git b448d1bf212219febbb182d00c210bad1bd25e7f)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: llvm-10.0/bin
shared:INFO: (Emscripten: Running sanity checks)

[kripken]

Which revision are you on? We fixed something related to that very recently, in https://github.com/emscripten-core/emscripten/pull/9197

If you are after that commit, and you still have the problem, is it possible that you still have something at system/include/libc/bits? Maybe a git merge left the removed symlink there for some reason (on windows git might just leave a text file there with the path - if that isn't removed, there will be problems). If so then a fresh checkout of latest incoming should work (or removing that old file manually).

[remoe]

I've used: https://github.com/emscripten-core/emscripten/archive/1.38.41.tar.gz

[kripken]

Ok, then correct, that archive is before that fix on the incoming branch. And the problem is that upstream LLVM landed a commit that breaks on that old code. So you can either use older LLVM, or use newer emscripten, or remove that file manually.

[remoe]

Ok, thanks. I've used now bef558affb630141e9fb0e955a9c444a87fb73fe (git clone) of emscripten. Then this error is gone. But then I have this error:

system_libs:WARNING: retrieving port: binaryen from https://github.com/WebAssembly/binaryen/archive/version_86.zip
system_libs:ERROR: a problem occurred when using an emscripten-ports library.  try to run `emcc --clear-ports` and then run this command again
cache:DEBUG: PID 17608 released multiprocess file lock to Emscripten cache at \.emscripten_cache\wasm-obj
Traceback (most recent call last):
  File "\emscripten-1.38.41\emcc.py", line 3555, in <module>
    sys.exit(run(sys.argv))
  File "\emscripten-1.38.41\emcc.py", line 1964, in run
    extra_files_to_link = system_libs.get_ports(shared.Settings)
  File "\emscripten-1.38.41\tools\system_libs.py", line 1547, in get_ports
    ret += [f for f in port.get(Ports, settings, shared) if not f.endswith('.txt')]
  File "\emscripten-1.38.41\tools\ports\binaryen.py", line 28, in get
    ports.fetch_project('binaryen', 'https://github.com/WebAssembly/binaryen/archive/' + TAG + '.zip', 'binaryen-' + TAG, sha512hash=HASH)
  File "\emscripten-1.38.41\tools\system_libs.py", line 1484, in fetch_project
    retrieve()
  File "\emscripten-1.38.41\tools\system_libs.py", line 1432, in retrieve
    f = urlopen(url)
  File "python27\lib\urllib2.py", line 127, in urlopen
    return _opener.open(url, data, timeout)
  File "python27\lib\urllib2.py", line 404, in open
    response = self._open(req, data)
  File "python27\lib\urllib2.py", line 422, in _open
    '_open', req)
  File "python27\lib\urllib2.py", line 382, in _call_chain
    result = func(*args)
  File "python27\lib\urllib2.py", line 1222, in https_open
    return self.do_open(httplib.HTTPSConnection, req)
  File "python27\lib\urllib2.py", line 1184, in do_open
    raise URLError(err)
urllib2.URLError: <urlopen error [Errno 1] _ssl.c:507: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version>

I've tried emcc --clear-ports. But it doesn't help. Is it possible that emscripten use my local version of "binaryen" ? My goal is to use emscripten without any additional downloads.

[kripken]

Yes, you can build binaryen yourself locally and make emscripten use that. Just update the BINARYEN_ROOT path in the .emscripten file (similar to how you tell it how to find a custom LLVM).

[remoe]

Thanks, I used now binaryen 88. Now it compiles some of the libs but crashes here:

cache:INFO: generating system library: libc.a... (this will be cached in ".emscripten_cache\wasm-obj\libc.a" for subsequent builds)
cache:INFO:  - ok
cache:INFO: generating system library: libcompiler_rt.a... (this will be cached in ".emscripten_cache\wasm-obj\libcompiler_rt.a" for subsequent builds)
cache:INFO:  - ok
cache:INFO: generating system library: libc-wasm.a... (this will be cached in ".emscripten_cache\wasm-obj\libc-wasm.a" for subsequent builds)
cache:INFO:  - ok
cache:INFO: generating system library: libdlmalloc.a... (this will be cached in ".emscripten_cache\wasm-obj\libdlmalloc.a" for subsequent builds)
cache:INFO:  - ok
cache:INFO: generating system library: libpthreads_stub.a... (this will be cached in ".emscripten_cache\wasm-obj\libpthreads_stub.a" for subsequent builds)
cache:INFO:  - ok
cache:INFO: generating system library: libcompiler_rt_wasm.a... (this will be cached in ".emscripten_cache\wasm-obj\libcompiler_rt_wasm.a" for subsequent builds)
cache:INFO:  - ok
cache:INFO: generating system library: libc_rt_wasm.a... (this will be cached in ".emscripten_cache\wasm-obj\libc_rt_wasm.a" for subsequent builds)
cache:INFO:  - ok
cache:INFO: generating system asset: generated_struct_info.json... (this will be cached in ".emscripten_cache\wasm-obj\generated_struct_info.json" for subsequent builds)
shared:ERROR: '/binaryen-88/bin\bin\wasm-emscripten-finalize appdata\local\temp\emscripten_temp_yktizg\tmp1egu5_.wasm -o appdata\local\temp\emscripten_temp_yktizg\tmp1egu5_.wasm.o.wasm --detect-features --global-base=1024' failed: [Error 2] The system cannot find the file specified

Should I open a new issue for this?

[kripken]

/binaryen-88/bin\bin\ looks like a bad path - did you add an extra bin in the .emscripten file? Removing it should fix that.

[remoe]

Yes, this was it. But LLVM_ROOT need this "bin" postfix ...

[fei2020]

I fix the same problem to just add include paths into my project makefile.

    CPP += -isystem $(EMSCRIPTEN)/system/include/libc
    CPP += -isystem $(EMSCRIPTEN)/system/lib/libc/musl/arch/emscripten
    CPP += -cxx-isystem $(EMSCRIPTEN)/system/include/libcxx

But my questions are: 1 Why the same micropython project get different when use different emscripten version? 2 Why $EMSCRIPTEN env var was geted rid of after emscripten 1.38.29. I am not sure the exact version. I just know 1.38.29 has $EMSCRIPTEN. But there is no in 1.38.33.

Thank you.

[sbc100]

You should never need to add those system include paths like that. Emscripten adds them internally. If you want to try debug this you could try adding -v to your compiler flags or if you really want to see a lot more info you can try setting EMCC_DEBUG=1 in the environment variable.

The reason to that emsdk stopped setting $EMSCRIPTEN is that its not necessary for emscripten itself. In fact it can lead to confusing/contradictory situations such as running emcc from one place with $EMSCRIPTEN pointing somewhere else. I'm very keen the emscripten should work out of the box without setting external environment variables.

In an example like the above you can find the emscripten root by looking at where the emcc compile is found. For example, something like $(dirname $(which emcc)) would do the trick in a shell script.

[LRLVEC]

Same problem. emcc --clear-ports helps.

[sbc100]

@LRLVEC can you share the full output of the failing command? Along with the output of emcc -v?