Ok, everything working fine after deleting the previous cmake build files. Am Donnerstag, 20. November 2014 23:16:50 UTC+1 schrieb Floh: > > Wait, this could be cached cmake build files. I DID have valgrind > installed recently and removed it when cleaning up my brew installation. > I'm currently testing after manually deleting the 'build_incoming_64' > directory under fastcomp. Will take a little while... > > Am Donnerstag, 20. November 2014 23:07:38 UTC+1 schrieb Floh: >> >> I'm getting a compile error with the emsdk with './emsdk install >> sdk-incoming-64bit' >> that <valgrind/valgrind.h> could not be found, currently investigating. >> There's an #ifdef HAVE_VALGRIND_VALGRIND_H in Support/Valgrind.cpp. >> Investigating... >> >> [ 6%] Building CXX object >> lib/Support/CMakeFiles/LLVMSupport.dir/Valgrind.cpp.o >> /Users/floh/projects/oryol/sdks/osx/emsdk_portable/clang/fastcomp/src/lib/Support/Valgrind.cpp:20:10: >> >> fatal error: >> 'valgrind/valgrind.h' file not found >> #include <valgrind/valgrind.h> >> ^ >> 1 error generated. >> make[2]: *** [lib/Support/CMakeFiles/LLVMSupport.dir/Valgrind.cpp.o] >> Error 1 >> >> Am Donnerstag, 20. November 2014 22:06:30 UTC+1 schrieb Alon Zakai: >>> >>> LLVM 3.4 from the pnacl tree has been merged into our incoming branches, >>> and the version number bumped to 1.27.1. See >>> https://github.com/kripken/emscripten-fastcomp/issues/51 for more >>> details. aidanhs did most of the hard work here - thanks! >>> >>> This is after a very long period of not updating LLVM or clang, mainly >>> due to less of a need (those updates are less significant than the 2.8-3.0 >>> days), also we wanted to let fastcomp stabilize without LLVM changes >>> happening, and finally just a matter of resources. But it's a good idea to >>> stay as close to upstream as possible. >>> >>> Our test suite passes (locally - bots are starting up now) and fuzzing >>> can't find any issues, but this is a large update, so please test carefully. >>> >>> Otherwise there shouldn't be major changes because of this. The update >>> fixes various bugs in LLVM, but doesn't bring major features as far as I >>> know, and no significant perf changes. Only thing I can think of offhand is >>> there is the optional 'mergefunc' pass which I hear is useful at reducing >>> code size, which works in 3.4 but didn't earlier. >>> >>> Note that LLVM stable is 3.5, and we are merging 3.4 here. That means we >>> are still 1 version behind (6 months). After 3.4 has been stable for a >>> while, we can start to consider when to move to 3.5. This is a larger >>> change as I hear they modified some core internal APIs, and also started to >>> require that the toolchain that builds LLVM support c++11. So we'll need to >>> be careful about when we do that. >>> >>> - Alon >>> >>>
-- 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.
