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

[Comer Duncan]

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

>
> 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
>
>
> _______________________________________________
> Users mailing list
> Users at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20150523/4e578f69/attachment-0001.html