let me first of apologize in case question unnecassary, new modifiying compilers , cross architectural designs.
in order evaluate performance on various platforms have been trying compile z3 smt solver on raspberry pi 2. there seems problem due arm architecture. intention far use configure script supplied mircrosoft research, works neatly , produces following outcome:
testing ar... testing g++... testing gcc... testing openmp... host platform: linux c++ compiler: g++ c compiler : gcc arithmetic: internal openmp: true prefix: /usr 64-bit: false python version: 2.7 writing build/makefile copied z3py example 'example.py' 'build' makefile generated. python packages dir: /usr/lib/python2.7/dist-packages compilation mode: release type 'cd build; make' build z3 when building first of encouter problem:
src/shell/install_tactic.cpp cc1plus: error: unrecognized command line option '-mfpmath=sse' cc1plus: error: unrecognized command line option 'u2018-msse' cc1plus: error: unrecognized command line option 'u2018-msse2' makefile:3159: recipe target 'shell/install_tactic.o' failed make: *** [shell/install_tactic.o] error 1 if understood meaning of error correctly, these commad line options refer clever tatics used compute mathematical exercises , not necessary if performance not issue. (simply speaking, should still work, if slower).removing flags respective config.mk, allows building extend.
after sucessfully producing lot of outcome files, make process terminates following error:
src/util/hwf.cpp ../src/util/hwf.cpp:55:23: fatal error: emmintrin.h: datei oder verzeichnis nicht gefunden compilation terminated. makefile:163: recipe target 'util/hwf.o' failed make: *** [util/hwf.o] error 1 my question is, whether again possible compile without using emmintrin.h (simply copying missing library pi not work, due architectural hurdles). has ever done this?
thank in advance helpful comments.
both, unsupported options , error in hwf.cpp refer support floating-point operations in z3. options trying make sure floating-point unit set correctly, , error in hwf.cpp because we're trying hardware intrinsics floating point operations. essentially, consequences of changes floating-point operations may imprecise if options removed; however, not many pieces of z3 rely on that, it's unlikely you'll see errors later.
i have rpi @ home, i'll see whether can use different options when home tonight. may rpi doesn't have floating point unit @ though, in case i'll have switch soft floats (which have support for, may slower).
