Ok. I can't believe this but I actually did it. I modified two files to get this working: system_libs.py where I updated the libcxx source files list and added a -DLIBCXX_BUILDING_LIBCXXABI=1 so libcxx knows that it is being compiled against libcxxabi. The second file I modified was shared.py where I reordered the default include directories.
I have another questions though, why is the symbols file needed to "cache-compile" libcxx? If it's that important can't we simply run llvm-nm over libcxx.a? And yeah, I will open a pull request soon for review :). Am Montag, 2. Mai 2016 16:16:53 UTC+2 schrieb [email protected]: > > I am currently trying to build libcxx but well I am having trouble. > The current problem is that I am getting the following compile error: > > In file included from > /home/user/dev/emscripten_dev/emscripten/system/lib/libcxx/exception.cpp:12: > In file included from > /home/user/dev/emscripten_dev/emscripten/system/include/libcxx/exception:81: > /home/user/dev/emscripten_dev/emscripten/system/include/libcxx/cstddef:43:15: > fatal error: 'stddef.h' file not > found > #include_next <stddef.h> > ^ > 1 error generated. > > #include_next is probably used to modify the system included stddef.h > header as the new version of libcxx provides their own > stddef.h/stdio.h/stdlib.h... > But clang couldn't find the header so I looked at the command line and > noticed that libcxx and libc include dirs should be swapped because > otherwise clang can't find the header, it's just how #include_next works I > guess. > > The old command line (obtained by EMCC_DEBUG=1): > > /home/user/dev/emscripten_dev/emscripten-fastcomp/build/bin/clang++ \ > -target asmjs-unknown-emscripten \ > -D__EMSCRIPTEN_major__=1 \ > -D__EMSCRIPTEN_minor__=36 \ > -D__EMSCRIPTEN_tiny__=3 \ > -Werror=implicit-function-declaration \ > -nostdinc \ > -Xclang \ > -nobuiltininc \ > -Xclang \ > -nostdsysteminc \ > -Xclang \ > -isystem/home/user/dev/emscripten_dev/emscripten/system/local/include \ > -Xclang \ > -isystem/home/user/dev/emscripten_dev/emscripten/system/include/compat > \ > -Xclang \ > -isystem/home/user/dev/emscripten_dev/emscripten/system/include \ > -Xclang \ > > -isystem/home/user/dev/emscripten_dev/emscripten/system/include/emscripten \ > -Xclang \ > -isystem/home/user/dev/emscripten_dev/emscripten/system/include/libc \ > -Xclang \ > > -isystem/home/user/dev/emscripten_dev/emscripten/system/lib/libc/musl/arch/emscripten > > \ > -Xclang \ > -isystem/home/user/dev/emscripten_dev/emscripten/system/include/libcxx > \ > -Xclang \ > > -isystem/home/user/dev/emscripten_dev/emscripten/system/lib/libcxxabi/include > \ > -std=c++11 \ > -Oz \ > -mllvm \ > -disable-llvm-optzns \ > > /home/user/dev/emscripten_dev/emscripten/system/lib/libcxx/exception.cpp \ > -Xclang \ > -isystem/home/user/dev/emscripten_dev/emscripten/system/include/SDL \ > -emit-llvm \ > -c \ > -o /tmp/tmprVBuXXXX > > I got this working by inserting > "-isystem/home/user/dev/emscripten_dev/emscripten/system/include/libcxx" > before the libc include dir. > > So the current workaround is to reorder the include dirs (libcxx before > libc becuase of libc header modified using libcxx headers) but I am not > exactly sure how I could implement a proper fix for this as emcc somehow > automatically adds these default compiler flags. Is there any way to change > this? > > Am Montag, 2. Mai 2016 02:17:18 UTC+2 schrieb Alon Zakai: >> >> We used to need some hacks due to limitations of our libc, but there have >> been fewer each time we update libc. I'm actually not sure if we need any >> more. It would be great it you checked if plain recent libcxx works, and if >> so, opened a PR with that update. >> >> On Sun, May 1, 2016 at 12:17 PM, <[email protected]> wrote: >> >>> Oh, I have just checked out the source of libcxx included in emscripten >>> and it seems that it has not been modified for emscripten. Am I wrong with >>> that? Does libcxx need modification to work with emscripten? In the case >>> that it doesn't any modification, it seems that I will give it a try using >>> a newer version of libcxx. >>> >>> Am Sonntag, 1. Mai 2016 20:59:09 UTC+2 schrieb [email protected]: >>>> >>>> Hey, >>>> >>>> I noticed that emscripten is using a pretty old version of libcxx and >>>> isn't fully C++14 compliant as for example there should be a constexpr >>>> version of operator[] in std::array but the constexpr version doesn't >>>> exist >>>> and so it means that that old version of libcxx may not fully support >>>> C++14. Is there any option to get an updated version of libcxx into >>>> emscripten? >>>> >>>> ~ Paul >>>> >>> -- >>> 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]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- 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]. For more options, visit https://groups.google.com/d/optout.
