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-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?