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

[Sean Farley]

On Wed, Jan 16, 2013 at 9:19 PM, Jeremy Huddleston Sequoia
<jeremyhu at macports.org> wrote:
>
> 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.

Apologies if that was too harsh. I didn't mean to sound like I was
biting back, but rather was trying to start a dialogue / point out a
different reasoning for multiple compilers. No offense / attack was
meant; sorry.

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

Ah, that would explain why there's no crash for the Apple compiler.
Thanks for explaining that.

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

Unfortunately, 1) I didn't report them at the time (and can't
reproduce) and 2) some of the repos are private :-(

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

Ah, I meant to explain the need for having multiple versions of a
library / program with different optimization levels for numerical
computation.

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

You are right to point out that a DAG alone won't solve compatibility
issues. I just meant that it's impossible to do correct dependency
analysis without having (or having something isomorphic to) 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.
>
> Please try to be specific about issues you are concerned with.

Agreed, I'll try to be more specific.

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

Sorry for the miscommunication, I just meant it as a real world bug I
ran into with using clang and that might be why someone needs to use
gcc. I wasn't expecting it to be fixed this soon.

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

I thought you were talking to the guy that reported the error?

> What other issues are you specifically frustrated with?

Pretty much just the ability to easily manage ports compiled with
different compilers.