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

[Ian Hinder]

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

> On Fri, May 22, 2015 at 12:38 PM, Ian Hinder <ian.hinder at aei.mpg.de> wrote:
> 
> On 22 May 2015, at 18:34, 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.
> 
> 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:

	https://github.com/live-clones/hdf5/commit/b283f087e32fb99023650240ef8290a3f46319c5

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. 

-- 
Ian Hinder
http://members.aei.mpg.de/ianhin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20150523/d5c62440/attachment.html