Closed HenryAWE closed 2 years ago
Some additional information
I've compiled AngelScript
library by Emscripten and it worked well. But when I link it with codes that has #include <iostream>
, this strange error occurs.
That is very odd. The code compiles just fine a simple em++ -c test.cc
call. Can you share the full emcc command that fails?
Sadly the makefile generated by cmake hides this command from you by default. You can work around this by running make VERBOSE=1
or by using -Gninja
which always shows the failing command. (I recommend using ninja for this and other reasons).
Are there any header files in /mnt/d/dev-wsl/submodule/submod
that might be confused for the system headers?
Are there any header files in
/mnt/d/dev-wsl/submodule/submod
that might be confused for the system headers?
There is only one header file for testing the sub-project function of CMake. But that header file only declares one simple function for testing and doesn't include any other header file. I think it won't confuse the system headers.
That is very odd. The code compiles just fine a simple
em++ -c test.cc
call. Can you share the full emcc command that fails?Sadly the makefile generated by cmake hides this command from you by default. You can work around this by running
make VERBOSE=1
or by using-Gninja
which always shows the failing command. (I recommend using ninja for this and other reasons).
I ran make VERBOSE=1
and the em++
command is as follow
[ 75%] Building CXX object CMakeFiles/main.dir/main.cpp.o
/mnt/d/dev-wsl/emsdk/upstream/emscripten/em++ @CMakeFiles/main.dir/includes_CXX.rsp -g -o CMakeFiles/main.dir/main.cpp.o -c /mnt/d/dev-wsl/submodule/main.cpp
I think the content of the includes_CXX.rsp
might be helpful
-I/mnt/d/dev-wsl/submodule/submod/. -isystem /mnt/d/dev-wsl/emsdk/upstream/emscripten/cache/sysroot/include
Can you add -v
to your CFLAGS and run again and include the full output.
Also, can you skip the whole cmake thing and just run via emcc -c main.cpp
.. that should give the same result but reduce the number of moving parts involved.
The problem is that -isystem /mnt/d/dev-wsl/emsdk/upstream/emscripten/cache/sysroot/include
being injected by cmake. Do you know where that is come from?
That is having the effect of putting the C headers before the C++ headers in the input path. Can you remove that addition? When you run emcc/clang you should see that C++ headers first in the include path:
#include <...> search starts here:
/usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/include/SDL
/usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/include/compat
/usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/include/c++/v1
/usr/local/google/home/sbc/dev/wasm/llvm-build/lib/clang/14.0.0/include
/usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/include
End of search list.
See how emscripten/cache/sysroot/include
comes last? In C++ mode the sysroot/include/stddef.h
should never get includes since the C++ version in lib/clang/14.0.0/include/stddef.h
will override.
I think the injection is caused by angelscript
installation. Because after I configured the library using emcmake cmake
and then compiled and installed it, its header was automatically installed in the Emscripten's sysroot/include
directory.
After moving the angelscript
's installation to a normal directory, this error disappeared.
It seems that this error is causing by emcmake
setting an inappropriate default install directory for cmake
's install
command.
sysroot/include
seems like a good default to me. Where else would you expect the install
step to put stuff by default?
Do you know why installing angelscript cause issues, does it contains headers or other files that conflict with or overwrite system headers?
I think default installation path needs a standalone path, which means it shouldn't mix with the system folder.
The angelscript
library only has a angelscript.h
and its header is installed in sysroot/include
by default. It is this header that let cmake
inject the include command that cause the trouble.
I searched the ChangeLog.md
and noticed a new feature added in version 2.0.24 - 06/10/2021
. It mentioned that Emscripten.cmake
will set cmake
's default install path to the sysroot
of Emscripten.
Link to the content in ChangeLog.md
Indeed, this is what emscripten does, but why is installing angelscript.h in this directory causing any issue? What are your resons for believing that.
From my POV the problem is the -isystem /mnt/d/dev-wsl/emsdk/upstream/emscripten/cache/sysroot/include
argument being passed to emscripten. Its because of this that the wrong version stddef.h
is being included. The one in /usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/include/c++/v1
should take precedence. Do you know how/why this argument is being added?
Make you could share your entire CMake project? It might help track down where this is coming from?
Do you know how/why this argument is being added?
Because angelscript.h
is installed to sysroot/include
by default. And then I use cmake's find_package()
command to locate the angelscript installation in the project, which will automatically set up the include directory and linking flags.
Besides, after I moved the angelscript to /mnt/d/dev-wsl/emlib/
and told this path to cmake manually , the include_CXX.rsp
's content (generated by cmake) changed to -isystem /mnt/d/dev-wsl/emlib/include
and the sysroot/include
disappeared.
I see, so cmake is using -isystem
here it inject paths to packages it finds. But it currently breaks the include order in emscripten if one adds -isystem
that points to sysroot/include
. This does seems like something that we can/should work around.
Simply telling cmake to install headers into some other folder is only a partial workaround since we have our own system packages that install into sysroot/include
(for example zlib). Any user that uses find_package
to locate zlib would presumably run into the same issue.
So I think we need to do some further investigation.
emcc
&em++
version: 2.0.31 My Code:Error Output: