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

[Sean Farley]

On Wed, Jan 16, 2013 at 7:16 PM, Jeremy Huddleston Sequoia
<jeremyhu at apple.com> wrote:
>
> On Jan 15, 2013, at 8:52 AM, Sean Farley <sean at macports.org> wrote:
>
>> On Mon, Jan 14, 2013 at 8:32 AM, David Barto <DBarto at visionpro.com> wrote:
>>> fails because the /usr/lib/libstdc++.so is found first. What can I do to
>>> find the proper /opt/local/lib/libstdc++.so?
>>>
>>> I've not modified the search paths in any way, I'm just trying to compile a
>>> c++ program using the newer standard features.
>>
>> Hmm, I can't reproduce this error. Using no special environment
>> variables and just a vanilla install of gcc47 on Mountain Lion, I get:
>
> <snip />
>
> Yeah, all of the MacPorts gcc compilers should be using /opt/local/lib/libstdc++.dylib instead of /usr/libstdc++.dylib.  This should "just work" … if you're seeing something differnet, it would be helpful to see how ld is being called by the compiler.  Run:
>
> g++-mp-4.7 -std=c++11 test11.cxx -v -Wl,-v
>
> ---
>
> 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.