Nice progress :) The symbols files are to check if we even need the library in the first place. Imagine a user that never builds with pthreads or libcxx, for example, so using the symbol files we know we don't need them at all. Otherwise we'd need to build every single system library up front.
On Mon, May 2, 2016 at 9:23 AM, <[email protected]> wrote: > 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. > -- 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.
