Hi Ian, I have downloaded a new version from scratch of Hilbert and have checked that I have installed all recommended macports, to wit:
ComerMacProRetina:~ comerduncan$ port installed pkgconfig gcc49 fftw-3 gsl jpeg zlib hdf5 openmpi openssl The following ports are currently installed: fftw-3 @3.3.4_1 (active) fftw-3 @3.3.4_1+universal gcc49 @4.9.2_1 (active) gsl @1.16_3 (active) gsl @1.16_3+gcc46 hdf5 @1.8.13_0+cxx+gcc46 hdf5 @1.8.14_0+cxx+fortran+gfortran hdf5 @1.8.14_0+cxx+gcc46 hdf5 @1.8.15_0+cxx+fortran+gfortran (active) hdf5 @1.8.15_0+cxx+gcc46 jpeg @9a_1 (active) openmpi @1.7.5_3 (active) openssl @1.0.1j_0 openssl @1.0.1j_0+universal openssl @1.0.2_0+universal openssl @1.0.2a_0 openssl @1.0.2a_0+universal (active) pkgconfig @0.28_0 (active) zlib @1.2.8_0 zlib @1.2.8_0+universal (active) I then put in the new version of detect.pl that Frank recommended. When I build using the osx-macports config file, I still (today!) get a crash before the build completes. I am sort of at a loss about what to do further. I could completely nuke macports and reinstall all, which will take quite a while, but can do that if there is a good chance that it will help. Do you have some recommendations of other things to try before the nuke option? Thanks. Comer On Fri, May 22, 2015 at 12:34 PM, Ian Hinder <[email protected]> wrote: > > On 22 May 2015, at 16:10, Roberto De Pietri <[email protected]> > wrote: > > Hi Ian: > > > Thanks for the answer. I followed exactly your procedure and I was very > surprised of having > a failing compilation. Than I starting tracing back the problem. > * All the thorns except one were compiling correctly. > * The failing thorn was CarpetIOHDF5 and of the 5 source files present > only 3 failed > * The error was very strange because the only real problem was related to > a system include > “/opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h” > and was related to conversion using AVX intel intrinsic. The error were > of the type: > > error: can’t convert between vector values of different size > return (__m64) __builtin_ia32_vec_init_v2si (__i, 0); > > > There is a stackoverflow post ( > http://stackoverflow.com/questions/19043109/gcc-4-8-1-combining-c-code-with-c11-code > ) which describes a similar problem, which I haven't studied in depth, but > they seem to suggest that it's a bug in gcc, and that setting > --std=gnu++11 instead of --std=c++11 in CXXFLAGS will work around the > problem. We currently have > > CXXFLAGS = -g -std=c++14 > > so I'm guessing that changing this to > > CXXFLAGS = -g -std=gnu++14 > > might have the same effect. > > What I don't understand is why we didn't pick this up in testing. I > successfully compiled the whole ET using exactly that set of MacPorts > packages and the optionlist before the release, and the gcc49 macports > package hasn't been updated since 4 weeks ago. > > When you say you followed exactly my procedure, do you mean that you get > the above compilation problem even when you have only the ports listed in > the optionlist installed, and have not installed anything else, such as > gcc5 or the python packages? > > -- > Ian Hinder > http://members.aei.mpg.de/ianhin > >
_______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
