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

[Jeremy Huddleston Sequoia]

On Jan 16, 2013, at 17:49, Sean Farley <sean at macports.org> wrote:

> 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.

Whoa … I'm simply asking if you're using g++ because you came across a bug in clang++ … there's no reason to get jumpy.  I, myself, test with a huge variety of compilers in order to discover potential code generation issues before they effect average developers.  Don't bite me for asking.

> 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

XCode 4.5 (and I think 4.4) was based on llvm 3.1

> , then everyone on a mac will run into this bug,
> 
> http://llvm.org/bugs/show_bug.cgi?id=14768

The compiler distributed with Xcode has assertions disabled by default, so end users are likely to not trip over that assertion.  What affect that actually has on generated code, I don't know… but thanks for pointing that out to me.

> I personally have had clang++ bugs with libmesh, moose, armadillo, and
> dolfin.

There are plenty of g++ bugs as well ;) … have you filed radars (or at least llvm bugzilla reports) about all of the clang issues you are finding?  Can you point me to them?

> 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."

I'm not really sure I know what you're referring to with the above sentence.

> 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).

How are you planning to manage the inherent difficulty with some clients using libstdc++ and libc++?  It's possible for two separate libraries to use different C++ runtime versions so long as they're not passing objects back and forth, but most of the time, libraries that are implemented in C++ provide C++ APIs to that library.

> 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.

Please try to be specific about issues you are concerned with.  

The bug you mentioned earlier was just reported two weeks ago, so you can't reasonably expect it to have been triaged and fixed by now unless you're willing to hack on the compiler yourself.  Additionally, you have the option of disabling assertions in clang if you want to get past it (although I don't know what the result would be since the assertion may actually be reasonable, or it may just be a bad assert … I haven't investigated).

Can you please provide the information I requested regarding libstdc++ linkage?

What other issues are you specifically frustrated with?

--Jeremy