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 ian.hinder@aei.mpg.de wrote:
On 22 May 2015, at 16:10, Roberto De Pietri roberto.depietri@unipr.it 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-... ) 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