This is not directly related to Android failure (sorry for the possible off topic), but there is also somewhat related failure that I have encountered in my application when building with boost 1.58 and clang compiler on OSX platform with precompiled headers enabled. It is far fetched, but Android issue and what I’m seeing on OSX platform could be caused by the same problem. Just to highlight the issue I’m having. When switching to boost 1.58 I’m consistently (but not exactly in the same places always) getting clang's segmentation fault, similar to the following * * * Stack dump: 0. Program arguments: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -cc1 -triple x86_64-apple-macosx10.9.0 -emit-obj -disable-free -disable-llvm-verifier -main-file-name main.cpp -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 241.9 -gdwarf-2 -coverage-file /private/tmp/ndn-cxx/build/tools/ndnsec/main.cpp.4.o -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0 -include-pch /private/tmp/ndn-cxx/build/ndn-cxx.2.pch -D NDEBUG -I /private/tmp/ndn-cxx/build/tools/ndnsec -I /private/tmp/ndn-cxx/tools/ndnsec -I /private/tmp/ndn-cxx/build/src -I /private/tmp/ndn-cxx/src -I /usr/local/include -stdlib=libc++ -O2 -Wall -Wno-error=unneeded-internal-declaration -Wno-error=deprecated-register -pedantic -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /private/tmp/ndn-cxx/build -ferror-limit 19 -fmessage-length 0 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.9.0 -fencode-extended-block-signature -fcxx-exceptions -fexceptions -fdiagnostics-show-option -vectorize-loops -vectorize-slp -o /private/tmp/ndn-cxx/build/tools/ndnsec/main.cpp.4.o -x c++ ../tools/ndnsec/main.cpp 1. <eof> parser at end of file 2. /usr/local/include/boost/date_time/date_parsing.hpp:104:5: instantiating function definition 'parse_date' 3. /usr/local/include/boost/lexical_cast.hpp:37:19: instantiating function definition 'lexical_cast' 4. /usr/local/include/boost/lexical_cast/try_lexical_convert.hpp:139:21: instantiating function definition 'try_lexical_convert' 5. /usr/local/include/boost/lexical_cast/detail/converter_lexical.hpp:472:32: instantiating function definition 'try_convert' clang: error: unable to execute command: Segmentation fault: 11 clang: error: clang frontend command failed due to signal (use -v to see invocation) Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn) Target: x86_64-apple-darwin13.3.0 Thread model: posix clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /var/folders/dn/40ynwmgj3kvfpdtwhv5jlhc80000gn/T/main-ffa9cd.cpp clang: note: diagnostic msg: /var/folders/dn/40ynwmgj3kvfpdtwhv5jlhc80000gn/T/main-ffa9cd.sh clang: note: diagnostic msg: * * * I don’t know what have/is caused the issue. This is probably because of some clang issue, as upgrading to the latest latest version (Apple LLVM version 6.1.0 (clang-602.0.49) (based on LLVM 3.6.0svn)) resolved the problem. Also, the issue does not exist when compiling without precompiled headers. — Alex

On May 17, 2015, at 10:52 AM, Dmitry Moskalchuk wrote:

On 17/05/15 19:48, John Maddock wrote:

...

Since all the Android/clang tests which use PCH are failing, can we either:

* Change the build options to disable PCH, or better, * Fix the clang toolset?

Someone who understands clang on Android would have to do the latter.

This is in my queue of tasks actually. Here is ticket: https://tracker.crystax.net/issues/952.

It's unclear what exactly wrong there, but I suspect it's something not hard to fix.

-- Dmitry Moskalchuk

On 17/05/15 20:52, Dmitry Moskalchuk wrote:

This is in my queue of tasks actually. Here is ticket: https://tracker.crystax.net/issues/952.

It's unclear what exactly wrong there, but I suspect it's something not hard to fix.

For the record: it was bug in our clang wrapper script, which improperly assumed that call was linking, not compilation of PCH. This is fixed now and such error must be eliminated in next reports. -- Dmitry Moskalchuk