[Users] failed build on local mac osx yosemite [POSSIBLE SOLUTION TO THE PROBLEM]

[Comer Duncan]

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 at aei.mpg.de> wrote:

>
> On 22 May 2015, at 16:10, Roberto De Pietri <roberto.depietri at 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?
>
> --
> Ian Hinder
> http://members.aei.mpg.de/ianhin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20150522/f46c6430/attachment.html