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

[Sean Farley]

On Wed, Jan 16, 2013 at 10:06 PM, Jeremy Huddleston Sequoia
<jeremyhu at macports.org> wrote:
>
> On Jan 16, 2013, at 19:44, Sean Farley <sean at macports.org> wrote:
>>>> 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 :-(
>
> With newer versions of clang, it will output the preprocessed source and a shell script to run to reproduce the issue with the preprocessed source.  If it's not private, simply providing those two files (source and script) are a big help to the developers.  If it is private, you can hopefully come up with a reduced test case within 10 minutes or so and submit that.  Also, you may feel more comfortable submitting pseudo-private test cases to bugreport.apple.com rather than the llvm bugzilla as it will then be between you and Apple.

I did not know that. That's pretty awesome, actually. I'll have to
keep it in mind.

>>>> 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.
>
> Ok, so you're analyzing the effects of different optimizations or something … yeah… in that case, you can't really work around it by using a different compiler or optimization set because you want to test *THAT* set.  That is certainly understandable.  You're bound to run into bugs with any compiler at -O3 and above.  Back when I was a Gentoo dev, I learned never to trust -O3 and above, and that rule has served me well.  Sometimes it's a corner case of a compiler bug, sometimes it's buggy source that "just works" without some strict optimizations… in general, if it's not widely tested, it's more likely to not work the way you want.  I don't really have a good answer to give you to this problem, but a good first step is to always report the bug.  Chance are you're one of a few people to ever trip over it based on your non-standard use case.

Agreed. We've filed many bug reports with Intel's compilers over the
years :-) In fact, Intel's -O3 _still_ crashes in some cases!

>>>> 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.
>
> Yeah, it would be great if dependencies were a nice tree, but they're not. =)

But! It is a graph! It's just sometimes a bad graph :-(

> Seriously though, if you're using C++ extensively in your ports, you should try intermixing some builds with clang++ using libc++ and see what happens.  New symbol mangling will make interoperability difficult.

I have put off doing this due to time. I have some pure C++ projects
to incorporate in the next few weeks that might be good candidates.

> We may need to figure out a way to deal with this ABI compatibility issue in base … is there currently a way to query what configure.compiler was for another installed port?

I ran into this issue as well but couldn't find an easy answer. I
solved it by using custom variants, e.g. petsc +debug +gcc47, and then
writing my own tool to activate / deactivate all dependent ports of a
certain variant at once so that I could switch, say, everything petsc
depended on to use +debug +gcc48.

>>> Can you please provide the information I requested regarding libstdc++ linkage?
>>
>> I thought you were talking to the guy that reported the error?
>
> Yeah, it's late.  Forgive me =)

No worries :-)

>>> What other issues are you specifically frustrated with?
>>
>> Pretty much just the ability to easily manage ports compiled with
>> different compilers.
>
> I don't think that will change any time soon.  It should hopefully be better now that we have just three C++ runtimes to worry about (host libstdc++, MacPorts libstdc++, and host libc++) instead of one for each gcc version … but things will get difficult if users start mixing libc++ and libstdc++.  You may see that I made a pass recently tackling some libc++ issues, and you can test your ports by adding -std=c++11 -lib=libstdc++ in configure.cxxflags.

Hmmm, this definitely reaffirms my decision to stick with strict C for
my dissertation :-) As for the other numerical packages I have in C++,
I'll have to slowly test them over the next few weeks as I have time.

I appreciate all the help in explaining these things and also
appreciate your efforts at Apple. Thanks, Jeremy!