Using -std=c++11 with the macports gcc-4.7 compiler

[Sean Farley]

On Wed, Jan 16, 2013 at 9:32 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> On Jan 16, 2013, at 19:49, Sean Farley wrote:
>
>> On Wed, Jan 16, 2013 at 7:16 PM, Jeremy Huddleston Sequoia wrote:
>>>
>>> That being said, is there something wrong with clang++ that is causing you to try g++ instead?
>>
>> Jeremy, please understand that this is a frustrating position / stance
>> to have from the perspective of the user. In the scientific community,
>> it is *expected* to try out all the compilers you have access to.
>> Usually, this just means Intel, Portland Group, IBM, and gcc; but now
>> it also includes clang. Also, there are _tons_ of reasons that
>> projects use different compilers. The most common is fortran (don't
>> even get me started on Apple stripping out gfortran from gcc 4.2 AND
>> THEN providing a bogus mpif{77,90} wrapper). If your project has both
>> C++ and Fortran dependencies, then the only way to compile the Fortran
>> is to install gcc4X. Well, that usually means your configure script
>> will also pick up gcc4X's C/C++ compiler.
>>
>> The second most common reason I've seen is the one you mention: errors
>> in the C++ compiler. If Apple decides to update their Xcode clang
>> version to 3.1 or later anytime soon, then everyone on a mac will run
>> into this bug,
>>
>> http://llvm.org/bugs/show_bug.cgi?id=14768
>>
>> I personally have had clang++ bugs with libmesh, moose, armadillo, and
>> dolfin. What makes this sentiment frustrating is the whole "use this
>> one version of the library with no optimization or debug control"
>> which is at odds with "try this library with {gcc,clang,etc.}'s
>> -O{1,2,3} and then write a paper about the results." This actually was
>> my whole motivation for writing scienceports: provide a way to use a
>> library with gcc4X or clang3X and somehow manage the combinatorial
>> explosion of variants (the correct data structure, by the way, is a
>> DAG).
>>
>> Ok, this rant is too long now. I hope no one is offended as I tried to
>> explain some of the science community's frustration.
>
> That's a valuable and valid viewpoint, and a totally reasonable answer to Jeremy's question. The need or want to compile some programs with different compilers or different compiler settings is a valid reason not to use clang. I'm guessing only a minority of our users are interested in that, and that only a minority of software would significantly benefit from such optimization, but that doesn't make it unimportant.

Thanks :-) There's a bit of a catch-22 here: most scientists don't use
macports because of the need to do this kind of operation; so there
could be more users that macports had. By the way, something like 90%
of the people working at Argonne have MacBooks (thank you, Taxpayers!)

You are right that most software wouldn't benefit from changing the
optimization level. It's even arguable about the numeric software but
that's another issue. Your domain is pretty much limited to dense
linear algebra or embarrassingly parallel data structures (e.g.
bioinformatics). That, of course, doesn't change people's minds that
they need it.

Anyway, if I understand it correctly, having multiple versions of a
library is basically equivalent to issue 126 :-) I was able to dance
around that issue by making a port group, though.

> But we must also understand Jeremy's viewpoint. You can see from his email address where he works. Clang is the compiler that OS X will use from now on; Xcode does not come with gcc anymore. So Apple clearly wants as much software to be compilable with Clang as possible, and wants to fix any bugs that are found with regard to that.

Sorry; I didn't mean to sound so critical. Perhaps it comes from the
long standing resentment about not including fortran and shipping a
broken mpi wrapper for two OS X versions :-( What I was more or less
trying to convey is the desire / need for easily switching compilers.
That will take much more discussion, though.