Since this seems to be a problem specifically with the intel compilers
my first instinct is to just remove the std=c++0x flag altogether.
However, I think that it's likely people will still want to use these
compilers since they are the latest (but certainly not greatest)
version. I hate to say it, but probably the best compromise is to add
a flag to "configure" like '-intel12' or something which can be
described as "Add fixes for intel compilers (may not work on all
platforms)" that will put the std flag in there.
Just to check, were there also any issues with the '-shared-intel' flag?
-Dan
On Wed, Feb 23, 2011 at 11:08 AM, Ben Roberts <ben.roberts.geek.nz> wrote:
>
> On 22/2/2011, at 3:56 p.m., Ben Roberts wrote:
>
>> I'll see if I can figure out what's going on at this end. I've attached the parts of the build log that failed at reduce, where the first failure occurred.
>>
>> The issues seem to arise from certain of the gcc-4.4 headers. I'm downloading and installing the MacPorts gcc-4.5 now to see if that makes a difference.
>
> In fact, it seems that this problem boils down to an imperfect implementation of the C++0x standard in Intel 11. See also:
>
> http://software.intel.com/en-us/forums/showthread.php?t=74691
>
> What are thoughts concerning compiler compatibility? Specifically, how backwards compatible should we aim to be?
>
> Ben
>
> --
> For greater security, I support S/MIME encryption.
>
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Feb 23 2011 - 10:00:04 PST
