Hi Ian,

I have elected to get the development version and have successfully done a build only changing the osx-macports.cfg to replace the default HDF5 = line to HDF5 = BUILD, as you suggested earlier today.  I am now running the static-tov test and see the beginning of reasonable output with the plots of rho max and alp looking ok.  

Thanks for the help from you Erik, Roberto, and Frank.  Should the macports version of HDF5 work compatibly with Cactus please let me know.  

Best regards,

Comer

On Sat, May 23, 2015 at 1:06 PM, Ian Hinder <ian.hinder@aei.mpg.de> wrote:

On 23 May 2015, at 05:08, Erik Schnetter <schnetter@cct.lsu.edu> wrote:

On Fri, May 22, 2015 at 12:38 PM, Ian Hinder <ian.hinder@aei.mpg.de> wrote:

On 22 May 2015, at 18:34, 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.
Yes, it seems that this describes the problem we're having. GCC uses __attribute__ to provide certain language extensions, e.g. for vectorization. These are not optional declarations -- these modify function definition and can't just be omitted.

And HDF5 does just that: it #defines __attribute__ to be empty (file H5api_adpt.h, near the beginning) if the file is included from C++. I have no idea why they would think this is legal, or why they would think this is even a good idea. We use __attribute__ in Cactus (after checking via autoconf whether it is supported) for a variety of optimizations and security checks.

I would try adding the line

#undef __attribute__

right after (below) any line that says

#include <hdf5.h>

to undo (part of) the damage that HDF5 does. We should also complain to the HDF5 authors.

So to summarise:

– HDF5 is undefining __attribute__, and this is a bug in hdf5.  
– In the stack overflow post, argp.h is undefining __attribute__, so this is a bug in glibc

Is that correct?  My suggestion to try --std=gnu++11 in CXXFLAGS won't fix the problem in the HFD5 header; it would only affect the argp.h problem, which doesn't apply to us.

Digging a bit deeper, it seems that we have been bitten (again) by trying to track a moving target.  The HDF5 MacPorts port was updated from 1.8.14 to 1.8.15 on 16-May-2015 (https://trac.macports.org/log/trunk/dports/science/hdf5/Portfile), 2 days before the ET release, and after the release branches had been created and the final testing had been done.  Note that this also happened with OpenMPI a few days before, introducing a critical regression which we were able to work around in time.

The responsible commit in HDF5 seems to be this one:


They were previously undefining __attribute__ only in H5private.h, which is included by hdf5 source files, but not from the public api used by user code, and this commit moves this definition into a public header file included by user code.  Erik, do you want to contact the developers, since you understand this better than I do?  

I think the most sensible workaround for us would be set HDF5_DIR = BUILD in osx-macports.cfg, since the current macports version is broken.  MacPorts has a single tree, they don't split into stable and unstable branches, presumably due to lack of resources.  The same is true of homebrew; presumably they will also update to 1.8.15 at some point, so maybe we should build HDF5 for homebrew as well.  The Cactus-provided version in ExternalLibraries is 1.8.14. 

-- 


_______________________________________________
Users mailing list
Users@einsteintoolkit.org
http://lists.einsteintoolkit.org/mailman/listinfo/users